Skip to content
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

fix: activate a temp environment when a sysimage is enabled #2700

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

pankgeorg
Copy link
Collaborator

Starting with Julia 1.8, the sysimage internal manifest (here on Ⅿ₀) is included in every Pkg resolution. So, a new, fresh manifest is equivalent to Ⅿ₀. This is strictly better than the "default" manifest that can be inconsistent with the Ⅿ₀, or may include packages that will interfere with the new packages we want to add (e.g. an old version of a package that the package you're adding is depending on).

To address that, the proposal is to instantiate a fresh manifest (temp=true) instead of the default.

Copy link
Contributor

github-actions bot commented Nov 1, 2023

Try this Pull Request!

Open Julia and type:

julia> import Pkg
julia> Pkg.activate(temp=true)
julia> Pkg.add(url="https://github.com/fonsp/Pluto.jl", rev="pg/activate-temp")
julia> using Pluto

@pankgeorg pankgeorg requested a review from fonsp November 1, 2023 13:46
@fonsp
Copy link
Owner

fonsp commented Nov 1, 2023

Oooh and can we get that internal manifest? is there also a project? in that case we should activate that internal environment, right?

@pankgeorg
Copy link
Collaborator Author

pankgeorg commented Nov 2, 2023

Oooh and can we get that internal manifest?

I don't think we can get the manifest, but the Pkg knows about it.

is there also a project? in that case we should activate that internal environment, right?

Hmm that's a good point. The most important repercussion I think is "What to serialize in cells "0000-...0001" and "0000-...0002", and I don't have a good answer, but I'll ask around

@fonsp
Copy link
Owner

fonsp commented Nov 5, 2023

I think the original assumption was that JH will open Pluto notebooks with a sysimage, and with the Manifest-and-Project-that-was-used-to-generate-the-sysimage stored as the global environment. If people were to use a Julia REPL, we want them to use the global environment, and this way we match that on Pluto.

Is that no longer the case? Happy to merge either way because JH is probably the only user.

@fonsp
Copy link
Owner

fonsp commented Nov 16, 2023

@pankgeorg

@pankgeorg
Copy link
Collaborator Author

I think the original assumption was that JH will open Pluto notebooks with a sysimage, and with the Manifest-and-Project-that-was-used-to-generate-the-sysimage stored as the global environment. If people were to use a Julia REPL, we want them to use the global environment, and this way we match that on Pluto.
Is that no longer the case? Happy to merge either way because JH is probably the only user.

I'm not sure that this is the case currently. Pluto runs with the sysimage and opens the notebooks with the sysimage. But Pkg.activate() doesn't necessarily activate the sysimage environment. And I think we don't need to either. Starting with Julia 1.9, I noticed that the internal pluto package manager does work with sysimages; it's just terribly slow. Maybe the right fix here is to teach it to be faster (e.g. ignoring or fast-pathing the resolution of Base._sysimage_modules). I need to investigate this a bit more.

@fonsp fonsp marked this pull request as draft November 20, 2023 11:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants