You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Parallel precompile is pretty much independent of Pkg. As Pkg is getting moved out of the sysimage it becomes awkward to have it there. For example, you still want parallel precompile for package load even if you haven't loaded Pkg in the session. And issues like JuliaLang/Pkg.jl#3442 also shows it is awkward to have to load Pkg in various environment just to get access to the precompilation feature.
The content you are editing has changed. Please copy your edits and refresh the page.
Once the code is moved over to Base it's going to be pretty difficult to maintain a version in Pkg on 1.10 which looks likely to become an LTS and in Base on 1.11+, so I've added all the filed issues that I think should be ideally dealt with before moving it over.
The list doesn't have to be completely done, it just makes it easier to do the more are.
One thing to bear in mind with this is that Pkg.precompile does extra Pkg things before precompiling if necessary, like resolve and instantiate. Once the parallel precompilation mechanic is in Base, if we wanted to avoid using Pkg in the code load precompilation path, there would need to be graceful errors if the environment isn't resolved or instantiated, telling the user to use Pkg to do that. That might be a bit of a UX regression.
Parallel precompile is pretty much independent of Pkg. As Pkg is getting moved out of the sysimage it becomes awkward to have it there. For example, you still want parallel precompile for package load even if you haven't loaded Pkg in the session. And issues like JuliaLang/Pkg.jl#3442 also shows it is awkward to have to load Pkg in various environment just to get access to the precompilation feature.
Tasks
The text was updated successfully, but these errors were encountered: