-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lazy artifacts cause precompilation-time warning #65
Comments
I agree - I'm not sure why we'd want lazy JLL artifacts to move the artifact download from What I really want is that if the package is never |
The progress bar is not even visible, so the precompile process can easily appear hung |
This is a bug/issue with the phase ordering in precompilation. Precompilation of the current package is special, e.g. we don't run So if a packages
Pkg, is only aware of the dependency graph, so we don't know under which conditions |
This was fixed in 1.10 by JuliaLang/Pkg.jl#3950, and in 1.11 by JuliaLang/Downloads.jl#257 |
Problem is that precompilation workloads nowadays cause loading packages before runtime. |
So what's the purpose of a JLL with lazy artifacts nowadays? |
MKL_jll was made lazy in JuliaPackaging/Yggdrasil#260 to address JuliaMath/FFTW.jl#133, and back then it did the job, because precompilation was a much lighter process and didn't typically cause packages to be actually loaded. With caching of native code in Julia v1.9 it's now much more likely that in a way or another a JLL is loaded thus triggering a lazy artifact to be downloaded. If anything, lazy artifacts are useful in cases where there are multiple alternative variants of builds, with lazy artifacts we effectively download only the default build, if they were all non-lazy we'd download loads of them (think of Enzyme_jlll which has about 300 different builds) |
That issue suggests that we've regressed on the intended behavior:
This isn't true any more - installing the package triggers parallel pre-compilation which triggers MKL_jll artifact downloads |
I don't think the download is being triggered by It seems to happen when pre-compiling the JLL itself:
edit: Looks like that probably regressed with #53? |
Uh, that looks possible. With JLLWrappers v1.4.1: $ JULIA_DEPOT_PATH=$(mktemp -d) julia +1.10 -e 'using Pkg; Pkg.add(; name="JLLWrappers", version=v"1.4.1"); Pkg.add("IntelOpenMP_jll")'
Installing known registries into `/tmp/tmp.ThLHUkl8qt`
Updating registry at `/tmp/tmp.ThLHUkl8qt/registries/General.toml`
Resolving package versions...
Installed Preferences ─ v1.4.3
Installed JLLWrappers ─ v1.4.1
Updating `/tmp/tmp.ThLHUkl8qt/environments/v1.10/Project.toml`
⌃ [692b3bcd] + JLLWrappers v1.4.1
Updating `/tmp/tmp.ThLHUkl8qt/environments/v1.10/Manifest.toml`
⌃ [692b3bcd] + JLLWrappers v1.4.1
[21216c6a] + Preferences v1.4.3
[ade2ca70] + Dates
[de0858da] + Printf
[fa267f1f] + TOML v1.0.3
[4ec0a83e] + Unicode
Info Packages marked with ⌃ have new versions available and may be upgradable.
Precompiling project...
2 dependencies successfully precompiled in 2 seconds
Resolving package versions...
Installed IntelOpenMP_jll ─ v2024.2.1+0
Updating `/tmp/tmp.ThLHUkl8qt/environments/v1.10/Project.toml`
[1d5cc7b8] + IntelOpenMP_jll v2024.2.1+0
Updating `/tmp/tmp.ThLHUkl8qt/environments/v1.10/Manifest.toml`
[1d5cc7b8] + IntelOpenMP_jll v2024.2.1+0
[0dad84c5] + ArgTools v1.1.1
[56f22d72] + Artifacts
[2a0f44e3] + Base64
[f43a241f] + Downloads v1.6.0
[7b1f6079] + FileWatching
[b77e0a4c] + InteractiveUtils
[4af54fe1] + LazyArtifacts
[b27032c2] + LibCURL v0.6.4
[76f85450] + LibGit2
[8f399da3] + Libdl
[56ddb016] + Logging
[d6f4376e] + Markdown
[ca575930] + NetworkOptions v1.2.0
[44cfe95a] + Pkg v1.10.0
[3fa0cd96] + REPL
[9a3f8284] + Random
[ea8e919c] + SHA v0.7.0
[9e88b42a] + Serialization
[6462fe0b] + Sockets
[a4e569a6] + Tar v1.10.0
[cf7118a7] + UUIDs
[deac9b47] + LibCURL_jll v8.4.0+0
[e37daf67] + LibGit2_jll v1.6.4+0
[29816b5a] + LibSSH2_jll v1.11.0+1
[c8ffd9c3] + MbedTLS_jll v2.28.2+1
[14a3606d] + MozillaCACerts_jll v2023.1.10
[83775a58] + Zlib_jll v1.2.13+1
[8e850ede] + nghttp2_jll v1.52.0+1
[3f19e933] + p7zip_jll v17.4.0+2
Precompiling project...
3 dependencies successfully precompiled in 1 seconds. 2 already precompiled. With latest version (v1.5.0): $ JULIA_DEPOT_PATH=$(mktemp -d) julia +1.10 -e 'using Pkg; Pkg.add("IntelOpenMP_jll")'
Installing known registries into `/tmp/tmp.xH9SI1wIde`
Updating registry at `/tmp/tmp.xH9SI1wIde/registries/General.toml`
Resolving package versions...
Installed Preferences ───── v1.4.3
Installed JLLWrappers ───── v1.5.0
Installed IntelOpenMP_jll ─ v2024.2.1+0
Updating `/tmp/tmp.xH9SI1wIde/environments/v1.10/Project.toml`
[1d5cc7b8] + IntelOpenMP_jll v2024.2.1+0
Updating `/tmp/tmp.xH9SI1wIde/environments/v1.10/Manifest.toml`
[692b3bcd] + JLLWrappers v1.5.0
[21216c6a] + Preferences v1.4.3
[1d5cc7b8] + IntelOpenMP_jll v2024.2.1+0
[0dad84c5] + ArgTools v1.1.1
[56f22d72] + Artifacts
[2a0f44e3] + Base64
[ade2ca70] + Dates
[f43a241f] + Downloads v1.6.0
[7b1f6079] + FileWatching
[b77e0a4c] + InteractiveUtils
[4af54fe1] + LazyArtifacts
[b27032c2] + LibCURL v0.6.4
[76f85450] + LibGit2
[8f399da3] + Libdl
[56ddb016] + Logging
[d6f4376e] + Markdown
[ca575930] + NetworkOptions v1.2.0
[44cfe95a] + Pkg v1.10.0
[de0858da] + Printf
[3fa0cd96] + REPL
[9a3f8284] + Random
[ea8e919c] + SHA v0.7.0
[9e88b42a] + Serialization
[6462fe0b] + Sockets
[fa267f1f] + TOML v1.0.3
[a4e569a6] + Tar v1.10.0
[cf7118a7] + UUIDs
[4ec0a83e] + Unicode
[deac9b47] + LibCURL_jll v8.4.0+0
[e37daf67] + LibGit2_jll v1.6.4+0
[29816b5a] + LibSSH2_jll v1.11.0+1
[c8ffd9c3] + MbedTLS_jll v2.28.2+1
[14a3606d] + MozillaCACerts_jll v2023.1.10
[83775a58] + Zlib_jll v1.2.13+1
[8e850ede] + nghttp2_jll v1.52.0+1
[3f19e933] + p7zip_jll v17.4.0+2
Precompiling project...
5 dependencies successfully precompiled in 34 seconds
1 dependency had output during precompilation:
┌ IntelOpenMP_jll
│ Downloading artifact: IntelOpenMP
│
│ [pid 2947122] waiting for IO to finish:
│ Handle type uv_handle_t->data
│ timer 0x23cc2c0->0x7fc56b8efb50
│ This means that a package has started a background task or event source that has not finished running. For precompilation to complete successfully, the event source needs to b
e closed explicitly. See the developer documentation on fixing precompilation hangs for more help.
│
│ [pid 2947122] waiting for IO to finish:
│ Handle type uv_handle_t->data
│ timer 0x23cc2c0->0x7fc56b8efb50
│ This means that a package has started a background task or event source that has not finished running. For precompilation to complete successfully, the event source needs to b
e closed explicitly. See the developer documentation on fixing precompilation hangs for more help.
└ Maybe we can turn the explicit call to |
As reported in JuliaGPU/CUDA.jl#2415: If a package (e.g. a JLL) has a lazy artifact that's used during precompilation, e.g. from
__init__
, that causes a precompilation-time warning:waiting for IO to finish:
:This is not a great user experience. It can be reproduced with plain JLLWrappers-generated code, as demonstrated in JuliaGPU/CUDA.jl#2415 (comment). I'm not sure whether this is a "bug"/feature of Pkg, or whether the JLLWrapper-generated code could be improved (e.g., shouldn't the download be postponed until run time, instead of precompilation time?).
The text was updated successfully, but these errors were encountered: