Why can I import a package not in my environment?

[Alseidon]

In an ongoing effort to be a bit cleaner in my environments and cleaning up my default env, I encountered a situation I do not understand: even though Plots isn’t added to the current environment, I can still import it.

(test_sysdynutils) pkg> st --manifest
Status `~/[...]/test_sysdynutils/Manifest.toml`
  [6ea1bd40] SysDynUtils v1.0.0-DEV `~/.julia/dev/SysDynUtils`
  [628e9319] TaylorInterface v0.1.1
  [8f399da3] Libdl
  [9a3f8284] Random
  [ea8e919c] SHA v0.7.0

julia> using Plots

(test_sysdynutils) pkg> activate
  Activating project at `~/.julia/environments/v1.10`

(@v1.10) pkg> remove Plots
    Updating `~/.julia/environments/v1.10/Project.toml`
  [91a5bcdd] - Plots v1.40.8
    Updating `~/.julia/environments/v1.10/Manifest.toml`
[Bunch of stuff removed]

julia> using Plots
 │ Package Plots not found, but a package named Plots is available from a registry. 
 │ Install package?
 │   (test_sysdynutils) pkg> add Plots 
 └ (y/n/o) [y]: n

How come? Is the default environment added to every other environment (I’d reckon that would be really bad for reproducibility)?

[gdalle]

Yes, the default environment is accessible from every other environment, see this thread for more details:

How does environment stacking work?

As @fbanning showed, the standard LOAD_PATH has three values. @stdlib is the standard library, @v#.# is the base environment of your Julia version (v1.6 for Julia 1.6 for instance, where added packages live that weren’t added in an activated environment) and @ refers to the currently activated environment if there is any. So when you call import or using, Julia goes through those sources in order to find the package to load, starting with a possibly activated local environment, then checking the…

The best practice is therefore to have basically nothing in the default environment, except pure development tools (Revise.jl, Cthulhu.jl, JET.jl, BenchmarkTools.jl, etc.)

[Alseidon]

Makes sense, thanks!