One of the reasons to introduce Pkg3 and the code loading rules was to make projects more reproducible.
This is why the following behaviour surprised me: when I switch to a new environment (] activate myenv), it is added to the environment stack (which now looks like [myenv, v1.0, stdlib]). This makes it difficult to make sure that I am not relying on packages that are part of the default environment, but not myenv and thus that submitting the manifest for myenv provides a full working environment to the end user.
Is there a way to replace the default environment instead of adding to the env-stack?
You can change your LOAD_PATH to be ["@", "@stdlib"] instead of the default ["@", "v#.#", "@stdlib"]. This can be accomplished by doing
in one of your shell startup scripts. Note, however, that having v1.0 in the environment stack only allows you to load packages in there from Main (so from the REPL or standalone scripts) and package code that doesn’t have any project file. From within code that does have a project file, you can only load dependencies that are explicitly declared in the project file’s [deps] section.
Yes, I am aware. I encountered this in trying to package a script (not a package). It worries me slightly though that this relies on the end-user to take action to set up the environment. Can I edit LOAD_PATH in the preamble to my script? I guess it should not matter as the packages installed on their machine are shadowed by my provided manifest…
Yes, just modify LOAD_PATH before loading packages.
Having a standard mechanism for providing scripts to users and running them with the right environment setup is a good thing that we’ll want to figure out a standard way to do in the future. I can imagine something like Julia scripts in the bin directory of a package being run from the package’s environment.