Feature request: activate environment on top of current stack

[nickrobinson251]

Sometimes it is useful to create a new environment stacked on the current environment
(where the current environment is not the "base" v1.x environment)

e.g. Have both "Level1" and "Level2" packages available by doing something like this

(v1.1) pkg> activate Level1
[ Info: activating new environment at ~/Level1.

(Level1) pkg> add Example
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
  Updating `~/Level1/Project.toml`
  [7876af07] + Example v0.5.1
  Updating `~/Level1/Manifest.toml`
  [7876af07] + Example v0.5.1
  ...

(Level1) pkg> activate Level2
[ Info: activating new environment at ~/Level2.

julia> using Example
ERROR: ArgumentError: Package Example not found in current path:
- Run `import Pkg; Pkg.add("Example")` to install the Example package.

Stacktrace:
 [1] require(::Module, ::Symbol) at ./loading.jl:823

julia> LOAD_PATH
3-element Array{String,1}:
 "@"
 "@v#.#"
 "@stdlib"

^ This doesn't stack Level2 on Level1

The workaround is to pushfirst!(LOAD_PATH, "path/to/Level1") (Thanks @fredrikekre for pointing this out).

e.g.

julia> pushfirst!(Base.LOAD_PATH, "/Users/nick/Level1")
6-element Array{String,1}:
 "/Users/nick/Level1"
 "@"
 "@v#.#"
 "@stdlib"

(Level2) pkg> status
    Status `~/Level2/Project.toml`
  (empty environment)

julia> using Example
[ Info: Precompiling Example [7876af07-990d-54b4-ab0e-23690620f79a]

Perhaps this can be an argument to activate? e.g. activate --stack Level2, to first add the current environment to the LOAD_PATH before activating the new one?

(I think this has some relation to #1233 ...and maybe #621)

[fredrikekre]

See also #1051

[KristofferC]

Sometimes it is useful to create a new environment stacked on the current environment

When is this? Something solved by #1233?

[nickrobinson251]

One example is developing tests for a package: instantiate a Project, add some test-only dependencies while working, they get added to deps, but you do not want them in deps. (Even if these test-only dependencies already exist in extras, they will be ignored by instantiated, and you need to add them and they get added to deps.)

Similar thing goes for developing a new feature, where you're experimenting with some new dependencies.

Seems like an example of a "sub-project", but #1233 is maybe trying to solve some more complicated cases than this too :)

[fredrikekre]

One example is developing tests for a package: instantiate a Project, add some test-only dependencies while working, they get added to deps, but you do not want them in deps. (Even if these test-only dependencies already exist in extras, they will be ignored by instantiated, and you need to add them and they get added to deps.)

This is basically #1233, and is essentially already working in Julia 1.2.

Similar thing goes for developing a new feature, where you're experimenting with some new dependencies.

Isn't this why we use git?

[nickrobinson251]

I think this could be solved without solving #1233 :)

(But hopefully solving #1233 hopefully solves this -- i feel like that's a good, more ambitious goal, and here i'm suggesting a nicer interface for a thing i thought was already possible i.e. stacking environments... maybe i'm wrong).

is essentially already working in Julia 1.2

i've not used Julia 1.2 yet, and do not know what's different, sorry. Are you saying #1233 is resolved in 1.2?

Isn't this why we use git?

Git can help me fix the unintended changes.

Access to different dependencies is why we use a package manager. I would like to have fixed list of "level1" packages that are accessible from a "level2" environment. This is already possible when "level1" is "v1.x", but not otherwise.