Global environment affecting local environment

I just ran julia --project in my locally developed package with only a few dependencies, and then ran Pkg.test(). However, for some reason, the package manager spends a bunch of time precompiling packages like Plots, and does this everytime I run tests.

Plots is not in Project.toml or Manifest.toml for my package’s environment. However, I noticed it was in my global environment, and it seems like the global environment’s packages remain active even when I activate a local environment. Is this behaviour expected, and how can I disable it?

You can set the JULIA_LOAD_PATH environment variable to @ before you start Julia.

For example, in Bash:

export JULIA_LOAD_PATH="@"
julia myscript.jl

I’m not sure of the corresponding syntax for PowerShell on Windows.

Got it. I feel like there should be an easier way to do this, like a script option, as the current state of affairs basically means that every local run of scripts or Pkg.test is affected by a potentially non-empty global environment, which could affect not just precompilation times but also correctness. (I understand why it’s useful for things like Revise.)

I can’t reproduce the issue

% JULIA_DEPOT_PATH="/tmp/214214" julia         
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.7.2 (2022-02-06)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

(v1.7) pkg> st
      Status `/private/tmp/214214/environments/v1.7/Project.toml`
  [91a5bcdd] Plots v1.29.1

julia> exit()
ian@ians-mbp CSV % JULIA_DEPOT_PATH="/tmp/214214" julia --project

shell> rm -rf /tmp/214214/compiled/v1.7/Plots

(CSV) pkg> test
     Testing CSV
      Status `/private/var/folders/_6/1yf6sj0950vcg4t91m9ltb5w0000gn/T/jl_M1Ip6M/Project.toml`
  [336ed68f] CSV v0.10.4 `/private/tmp/214214/dev/CSV`
  [944b1d66] CodecZlib v0.7.0
  ...
      Status `/private/var/folders/_6/1yf6sj0950vcg4t91m9ltb5w0000gn/T/jl_M1Ip6M/Manifest.toml`
  [336ed68f] CSV v0.10.4 `/private/tmp/214214/dev/CSV`
  ...
     Testing Running tests...

Pkg.test() did no precompilation. If I understand your issue, the above should be a MWE?

Right. My test script was actually activating another environment that imported Plots, which was the true cause of the precompilation, so that was my bad.

I still think it would be nice to have an easy way to not include the global environment – or at least further emphasize to users that the global environment should be treated with extreme care as it is included by default everywhere. (It’s also super easy to pollute the global environment: just forget to activate your local environment.)

Intuitively, based on the docs I’ve read so far on environments, I thought of the global environment with its Project.toml as just another environment. It feels very unintuitive that I can do using Plots in julia --project in the above example, even though Plots is not returned by ] st.

1 Like

Yep, I agree. In particular with the point that it is to easy to pollute the global environment. IMO the default environment shouldn’t be the one that is global in the sense of being automatically stacked on top of local environments.

(I also think that stacking should be opt-in.)

Note however that this has been raised a few times before and, unfortunately, hasn’t led to a change. Maybe it’s just because no one went ahead and created a PR. Maybe it’s because there is no consensus. Don’t know.

2 Likes

That mostly. One if these discussions led to this small package aiming a more practical and less intrusive prototyping: GitHub - feanor12/Draft.jl: A small package to automatically create temporary environments in offline mode.

The idea is to start Julia in a temporary environment which can nevertheless be saved, and use in practical way locally available packages. (and with that keep the global environment mostly clean).