no-arg activate: if already deactivated, activate current project

[StefanKarpinski]

• home project: remove all uses of this (no longer does anything as of active project: get rid of the concept of a home project julia#36434)

• Previously there was no convenient way to activate the current project from the Pkg REPL or API. This changes Pkg.activate() so that if there is no active project to deactivate, it instead activates Base.current_project(). This means that we can now say that julia --project is exactly equivlent to julia followed by pkg> activate.

[StefanKarpinski]

well that may have broken some things

[StefanKarpinski]

Marking as 1.6 mostly as a reminder to myself to get this passing tests at some point before then.

[danielwe]

Coming here from #3547 and just wanted to confirm that this is the intended behavior for repeated no-arg calls to activate:

• First call: discard and forget any active environment set via JULIA_PROJECT or the --project parameter at startup, or via subsequent activate calls with argument. Unless LOAD_PATH has been modified, this activates the base @v1.x environment.
• Second call: activate current_project(), which is determined based on the current working directory (as if --project=@. were passed at startup)
• Subsequent calls: toggle between the latter two

I confess I'd be surprised by this behavior, specifically having the environment I provided on the command line forgotten while an unrelated non-base environment is brought into orbit. Wouldn't it make more sense to toggle back to the previously active environment rather than current_project()?

EDIT: I suppose that last suggestion is exactly the concept of a home project that you've excised, so I don't expect that to make a comeback. But isn't the behavior introduced here even more confusing?

[Socob]

I agree that it’s very confusing to make the behavior of activate without arguments depend on the current state. Further, after all this time, it’d be yet another breaking change in the behavior of an existing function.

If all that’s needed is a convenient way to activate the current project, this could simply be added as a new flag, i. e. Pkg.activate(current=true) and ] activate --current, or as a separate function, Pkg.activate_current() and ] activate_current.

[StefanKarpinski]

Further, after all this time, it’d be yet another breaking change in the behavior of an existing function.

SemVer doesn't apply to interactive functionality, so that argument does not prevent changing this. It's worth taking into consideration, but we are free to alter interactive interfaces like Pkg and the REPL.

[Socob]

I wasn’t aware that Pkg was considered an interactive interface! Is this stated anywhere? I’m certainly using it in a non-interactive way! What is the stable interface to accomplish the same things?

[StefanKarpinski]

If you're talking about the API then that should remain compatible, but the Pkg REPL certainly is interactive. I don't really feel strongly about this issue, btw, just seemed like this would be convenient.

[Socob]

I was referring to the function Pkg.activate (see above), since this is what you were changing in this PR. (As it’s defined in API.jl, I’m assuming that this is part of the API you mentioned.) The behavior of this function/API was already broken once by the changes in JuliaLang/julia#36434 (see #3127), apparently without much/any announcement (at least on the Pkg.jl side) or changes to the documentation (#3547, JuliaLang/julia#50527). I agree that it would be nice to have an easy way to activate the current project (moreso on the interactive side, since using the API, you can already just do Pkg.activate(Base.current_project())), but that the API shouldn’t be broken for no reason.

(Side note: In principle, I do think it was a good idea to get rid of the “home project” concept, since it just added unnecessary complexity and confusion.)