-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Downloads EASY_HOOK regression in v1.11.0? #56091
Comments
Doing something like
I get
so the hook is at least running... |
Changed it to: # This file should contain site-specific commands to be executed on Julia startup;
# Users may store their own personal commands in `~/.julia/config/startup.jl`.
println("Defo read startup file!")
using Downloads
Downloads.DOWNLOADER[] = nothing
Downloads.EASY_HOOK[] = (easy, info) -> begin
println("RUNNING EASY HOOK!!!")
end
|
Diff between Downloads.jl in v1.10.5 vs v1.11.0 is JuliaLang/Downloads.jl@ead289a...89d3c7d, it shouldn't be difficult to bisect (assuming the issue is there and not somewhere else). |
Can you try load Pkg, set the hook through |
@KristofferC It works fine if done like that:
In fact, it works fine, just going:
It's just going via the REPL where it gets upset. |
So this seems to be a With
Perhaps this is a windows-specific issue. |
That's because whether Often a stdlib ends up pre-compiled for an unrelated project/workflow, and then the pre-compiled stdlib starts to load as a duplicate version everywhere You have to check via |
The premise of
|
I very much appreciate you being enlightened about this. So removing use of "public globals" is the fix? |
One fix would be to move the globals in question into Base, where uniqueness is still a thing |
Yeah.. I'm not happy about the restrictions either TBH. I think they're a rough combo of unintuitive, hard to enforce, and lead to rare bugs (that they are rare is worse, not better IMO) but it's the situation we have right now Moving the globals to Base should fix the issue FWIW, I don't really know why we added this behavior to require_stdlib in the first place. It might be worth revisiting? |
IIUC at least one of the reasons was to ensure that if the user wants to use a newer stdlib version than was bundled, say Pkg, we can still load the version that the repl expects, to avoid breakage. It has been a bumpy road for sure.. |
Oof. Moving these into Base is going to be non-trivial..
You can't update |
For Pkg, if you update it, I would want the repl to be the updated one. We just have to fix the common load failures from out of date manifests. |
This is fixed by #55908, which was marked for backporting to avoid this issue |
I have this as my startup.jl file:
In 1.10.5 everything's fine:
In 1.11.0, it's not, trying to add anything that has an artifact will fail.
The text was updated successfully, but these errors were encountered: