REPL environment handling

[00vareladavid]

I just wanted to sketch some ideas out, and possibly collect some pros/cons

• make activate the default command in the REPL.
  For example: pkg> dev/Foo or pkg> v1.0
• use @ to mean related environment, this would work in conjunction with the new isolation system
  For example: add Test @test or add Foo @deps or even add Foo @dev/Bar
• environment history i.e. remember last environment
  For example: pkg> add Foo, pkg> activate @test, pkg> add Test, pkg> activate -

[00vareladavid]

This would conflict with the syntax proposed in #930. I'm pretty sure we could alternatively use + for this e.g. add Test +test. I think I actually like + better for this usecase 🤔

[00vareladavid]

#480 is a subset of this

[StefanKarpinski]

I wonder if the @ syntax could be made to work somehow. E.g. @tools is the named environment ~/.julia/environments/tools and MyPkg@test is the test sub-environment of the MyPkg project. But MyPkg+test is pretty good as well: it conveys the idea that it's the same things as the MyPkg environment plus some other things. However, are MyPkg's dependencies directly available from MyPkg+test? Or does MyPkg+test depend on MyPkg so the dependencies are there but only indirectly?

[StefanKarpinski]

pkg> activate - would be nice, although I wonder if we wouldn't want a stack then...

[StefanKarpinski]

We need to be a bit careful to create the right mental navigation model. Currently the model is: there's a current active environment and home environment. If we have pkg> activate - and someone does pkg> activate to go home, what does pkg> activate - do after that? Have we popped the entire stack or is the history mechanism separate from the home mechanism? I suspect that what people would want pkg> activate - to take them back to where they just were even after pkg> activate to go home. Which suggests that the home mechanism and the history mechanism are independent. Do we want to only allow one step back or arbitrarily many?

[00vareladavid]

Or does MyPkg+test depend on MyPkg so the dependencies are there but only indirectly?

Yeah, that's the current way the sandbox works.

Which suggests that the home mechanism and the history mechanism are independent

Agreed.

Do we want to only allow one step back or arbitrarily many?

My personal preference is only one. A lot of CLIs have similar features but I almost never need to pop back more than once. On the rare occurrence that I require a full stack, I forget the syntax and just do it manually anyway. That being said, I don't feel strongly either way.

[00vareladavid]

To elaborate, the REPL features in this PR are meant to be used when someone needs to quickly (and lightly) navigate between related environments. For heavier env navigation, something like #621 seems more appropriate.

[StefanKarpinski]

Ok, so that seems simple enough then: pkg> activate - is a special syntax for re-activate the last environment. We'll need a LAST_PROJECT variable that stores whatever that is and swaps ACTIVE_PROJECT and LAST_PROJECT when that happens.

[00vareladavid]

Feels good:

(v1.0) pkg> activate
[ Info: activating environment at `~/pkg/Pkg.jl/Project.toml`.

(Pkg) pkg> activate +test
[ Info: activating new environment at `~/pkg/Pkg.jl/test/Project.toml`.

(test) pkg> activate -
[ Info: activating environment at `~/pkg/Pkg.jl/Project.toml`.

[fredrikekre]

* make `activate` the default command in the REPL.

I very much dislike this, and I don't understand why it would be good. Would pkg> asdf then be valid input and mean pkg> activate asdf? And what would pkg> test do? Run tests or activate a test env?

[00vareladavid]

Ok 🙂. I was on the fence about the feature you mention, but it doesn't seem worth the complexity.

[00vareladavid]

I still haven't even implemented add Test +test syntax yet. I kind of like it (feels nice and DWIMy), but I'm not sure how useful it will end up being.

The current alternative would be:

(Pkg) pkg> activate +test
[ Info: activating new environment at `~/pkg/Pkg.jl/test/Project.toml`.

(test) pkg> add Foo Bar
...

(test) pkg> activate -
[ Info: activating environment at `~/pkg/Pkg.jl/Project.toml`.

This feels snappy enough, and it comes at minimal implementation cost.

[00vareladavid]

I also like the nice "push/pull" with the +/- characters

[fredrikekre]

So activate +test would mean activate $(path to current project)/test?

[00vareladavid]

Yeah, it will give users a convenient syntax to interact with "sandbox" environments.

[fredrikekre]

Personally I don't think this would make my workflow any more convenient. When I am working on a project I generally have pwd set to that folder, and start julia with --project which means that this works already:

activate test
add A B
activate

Is it really worth the extra complexity to support

activate +test
add A B
activate -

which is basically the same thing but just another thing to learn?
Also, the good thing IMO with the sandbox environments is that they are not special in any way; the are just regular environments. The + syntax would make them special in some way, which I am not sure is a good thing.

[00vareladavid]

The cost for both - and +test combined is roughly 20 LOC (probably a bit less). It only exists in the argument parsing for activate so it is decoupled from the rest of the system. The main problem I see with the workflow you propose is that it couples env navigation with the home project. For example: what if someone wants to work on multiple environments at the same time? What if someone wants to work on a newly generated environment?

[fredrikekre]

The cost for both - and +test combined is roughly 20 LOC (probably a bit less).

Sure, it might not be much implementation complexity, but it is extra syntax to communicate in docs and answer questions for. Is that worth it?

For example: what if someone wants to work on multiple environments at the same time?

I don't think you jump between the sandbox envs. If you have a project with A and B you typically jump between A/Project.toml and B/Project.toml not between A/Project.toml, A/test/Project.toml, B/Project.toml and B/test/Project.toml.

What if someone wants to work on a newly generated environment?

What do you mean? activate path should work just fine here.

[00vareladavid]

The core issue is users have no convenient way to activate the test environment.

Without this syntax, users have two alternatives:

• Type out the full path to the test environment and then type out the path to the parent environment when you are done.
• Set both the working directory and the home environment just so the activate commands are simple.

With this syntax:

• Use activate +test when you want to activate the test environment. Use activate - to go back.

[00vareladavid]

Honestly, I don't see the reason for pushback on this

[fredrikekre]

With this syntax:
* Use activate +test when you want to activate the test environment. Use activate - to go back.

But you still need to type out the full path to the parent project first, just to then be able to use +test? So why introduce

        (v1) pkg> activate /path/to/dependency
(dependency) pkg> activate +test
      (test) pkg> activate -
(dependency) pkg> activate -        ???
        (v1) pkg>

when we already have

        (v1) pkg> activate /path/to/dependency/test
      (test) pkg> activate
        (v1) pkg>

* Set **both** the working directory and the home environment just so the `activate` commands are simple.

Yea, but isn't this typically what you have anyway? Why not use the tools with home project and active project that are already available?

I also feel like you are only really interested in activating the test env when you are working on that particular project. If you develop multiple packages, e.g. from (v1) you might jump between A/Project.toml and B/Project.toml, but you are not interested in activating their test envs.

This is also not something that has been requested by anyone, or something that has been brought up as an annoyance. You are the only one that have argumented for this, so would be good to hear other peoples input.

[00vareladavid]

Yea, but isn't this typically what you have anyway?

I personally almost never use --project. And I'm frequently surprised by the way people end up using Pkg.

Why not use the tools with home project and active project that are already available?

Because this presupposes a particular workflow. I wouldn't want to force users to work a certain way unless there is a compelling reason to do so.

This is also not something that has been requested by anyone.

add Test +test is inspired by #480. Relative paths were requested in #1025, shortly after I pitched this PR.

[StefanKarpinski]

I'm frequently surprised by the way people end up using Pkg.

You and me both. It's fascinating to see what people come up with.

[00vareladavid]

closed by #1488