Stacked environments

General Usage
,
1

I’d like to start making better use of stacked environments and have a few questions.

If I’m not mistaken the only sanctioned way to add another stacked environment is by modifying LOAD_PATH, e.g. push!(LOAD_PATH, "@myenv") (generally one would want this at the . Or alternatively by setting the JULIA_LOAD_PATH environment variable. The disadvantage of the latter is that it doesn’t just add to the default LOAD_PATH, it replaces it, so if you want to just add then the options are either to explicitly include the defaults (JULIA_LOAD_PATH=@:@v#.#:@stdlib:@myenv) or by doing the push! in startup.jl. Am I correct that this is basically what’s available for starting a REPL session with an additional stacked environment? How would it be accomplished for IJulia and Pluto?

Next I’m wondering, other than having to ] activate @myenv, ] status, and ] activate <previous env> to get back to where I was, is there some way to determine what modules are available for import / using beyond those in my primary environment? I guess this question isn’t just about additional stacked environments but applies to the default ones too. I can of course do a tab-complete on using but that doesn’t tell me what environment is providing a given module.

Finally I’m wondering about how people version control their shared/stacked environments. Do you simply make ~/.julia/environments/myenv a git repo? There’s nothing in Pkg.jl that can help with managing these, right? I’m thinking about how one would maintain some standard shared environment for use by a team.

Also if anyone has general workflow tips on using stacked/shared environments I’d be interested to hear. The docs basically describe how they work but don’t really offer much in the way of how to make use of these tools.

2

Note that stacked environments are mainly for interactive use and convenience. In my main shared environment, I only have utilities. For most purposes, you will want to actually add any packages you are going to use for that project or package to the top level project environment that you have loaded.

See Base.load_path() for actual resolution of the LOAD_PATH and thus the location of the environments.

julia> Base.load_path()
2-element Vector{String}:
 "~/.julia/environments/v1.9/Project.toml"
 "~/src/julia-1.9.0-beta3/share/julia/stdlib/v1.9"

help?> Base.load_path()
  load_path()

  Return the fully expanded value of LOAD_PATH that is searched for projects
  and packages.

For the most part, you could query Base.load_path(), iterate through the paths, activating the environments as you go, and then use Pkg.dependencies() to gather the available packages, reactivating the original environment at the end.

Also see

3

What I’m aiming to do is keep my main shared environment (i.e. @v#.#) very sparse, with only things that I expect to want to be available in pretty much any interactive session (OhMyREPL, Revise, BenchmarkTools). I want to also have a “batteries included” shared env that I would use when I want a much larger set of fairly general-purpose packages available to me (plotting, profiling, statistics, CSV, JSON3, DataFrames, etc.). I’m calling that one @patlab because it’s a bit like how everything is available in Matlab (though using/import will still be required).

I’ll give that a go, thanks!