-
Notifications
You must be signed in to change notification settings - Fork 2
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
avoid loading pkg until needed #1
base: main
Are you sure you want to change the base?
Conversation
1c85c60
to
f66d10a
Compare
f66d10a
to
362299d
Compare
Should delete Line 6 in c1c1c7a
|
I'm not sure about that. I think we need the Project dependency even if we're not always loading. |
Ah, is that because of LazyArtifacts.jl/src/LazyArtifacts.jl Line 52 in 362299d
|
src/LazyArtifacts.jl
Outdated
if !artifact_exists(hash) | ||
# loading Pkg is a bit slow, so we only do it if we need to | ||
# and do it in a subprocess to avoid precompilation complexity | ||
cmd = run(pipeline(`$(Base.julia_cmd()) -E ' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the benefit of subbing out to another process vs. doing something like Base.inference_barrier
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vtjnash would that work? It'd be nice to not have to manage the download progress bar behavior coming from the sub process, while being able to read back the resulting path at the end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you cannot unload it without a process, so it is illegal to load during precompile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see; yes, if this is run during precompilation, loading another module will screw up the precompilation output, so that makes sense.
4e56e8b
to
2a6b4e4
Compare
I build julia with this locally and confirmed that the progress bar shows properly with overprinting etc.
|
This comment was marked as resolved.
This comment was marked as resolved.
src/LazyArtifacts.jl
Outdated
Pkg = Base.require_stdlib(Base.PkgId(Base.UUID("44cfe95a-1eb2-52ea-b672-e2afdf69b78f"), "Pkg")); | ||
Pkg.Artifacts.try_artifact_download_sources( | ||
$(repr(name)), | ||
Base.$(repr(hash)), | ||
$(repr(meta)), | ||
$(repr(artifacts_toml)); | ||
platform = Base.BinaryPlatforms.$(repr(platform)), | ||
verbose = $(repr(verbose)), | ||
quiet_download = $(repr(quiet_download)), | ||
io = stderr | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, unfortunately running a sub-process with dynamic code like this is very incompatible with --trim
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #1 (comment) for some discussion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to do this only during pre-compilation? That behavior on its own is fine, but doing it at runtime is problematic for --trim
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to do this only during pre-compilation?
If we revert JuliaPackaging/JLLWrappers.jl#66 yes 😛
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really agree that lazy artifacts are incompatible with AOT compilation - but they are definitely incompatible with the idea of providing a self-contained executable/package
My request was for this to be branched on Base.generating_output()
because the true
branch is not inferable/compilable for juliac
, but we have ways to let juliac
know that only the false
branch is ever taken at run-time.
In that case, you're still running an AOT-compiled executable and the download works - it just happens lazily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Didn't see Cody's reply before sending this)
I think the question here is more about legality, rather than preference that something orchestrating --trim
would have for artifact downloads a la PackageCompiler.
As it is now seems more generally legal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, I fear that Base.require_stdlib
is still going to be effectively impossible for us to infer
We're not even allowed to load the stdlib for inference on its own functions, because that would break the same pre-compilation assumptions we're skirting in the other branch.
I'm a bit worried that this change just makes LazyArtifacts incompatible with --trim
unfortunately
We might have to find a way to load Pkg eagerly for --trim
alone (which unfortunately means that AOT-compiled applications don't get this speed up)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if you can infer it directly, but you should be able to pre-emulate it, since it is just a shim for finding the right .ji
file to load, and that can be pre-computed and run directly (esp. for --trim)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right but then I need to infer Pkg.Artifacts.try_artifact_download_sources
and also ensure that its code is available in the loaded pkgimage (or our own sysimage)
How did we get into this situation where LazyArtifacts depends on Pkg for this implementation, instead of vice-versa? I'm probably missing some historical context.. But it feels like this would maybe better be solved by getting the code out of Pkg? |
Others here may be able to correct/expand.. but: Because Pkg used to be in the sysimage so was fast, and downloading artifacts is handled by Pkg at i.e. I think if we simply wanted to merge Pkg.Artifacts into Artifacts it would have to take on Downloads ,Tar, TOML, LibGit2 and also take with it the Pkg.GitTools module. Artifacts currently has no deps. |
Originally, everything having to do with packages was in |
Before merge I should add a test for the fork done during precompilation. |
I did some experimenting - Ripping out the relevant bits doesn't look too bad: JuliaLang/julia#55755 |
Fixes JuliaLang/julia#55725
This PR
julia master