active project: get rid of the concept of a home project

[StefanKarpinski]

This makes doing julia --project equivalent to activating the project that the current directory is in at Julia startup. What this means is that if you do pkg> activate instead of taking you back to whatever project was initially active, it will make it as if you had never activated a project in the first place.

I think the "home project" idea is more confusing than it's worth and I do actually quite often want to deactivate the current project and get access to whatever the fallback active project would be, i.e. @v1.6, so this simpler version of this seems not only easier to explain but also more useful.

cc @fredrikekre, @KristofferC

[StefanKarpinski]

I need feedback on the idea more than the implementation (which I'm fairly confident about), but of course code review is always good to have as well.

[StefanKarpinski]

Perhaps best explained with an example. Without this PR:

$ cd ~/dev/Pkg
$ julia -q --project
(Pkg) pkg> st
Project Pkg v1.5.0
Status `~/dev/Pkg/Project.toml`
  [ade2ca70] Dates
  [76f85450] LibGit2
  [8f399da3] Libdl
  [56ddb016] Logging
  [d6f4376e] Markdown
  [de0858da] Printf
  [3fa0cd96] REPL
  [9a3f8284] Random
  [ea8e919c] SHA
  [cf7118a7] UUIDs

(Pkg) pkg> activate
 Activating environment at `~/dev/Pkg/Project.toml`

(Pkg) pkg>

Here activate does nothing because we're already in the home directory and haven't explicitly activated anything. With this PR this is different:

$ cd ~/dev/Pkg
$ julia -q --project
(Pkg) pkg> st
Project Pkg v1.5.0
Status `~/dev/Pkg/Project.toml`
  [ade2ca70] Dates
  [76f85450] LibGit2
  [8f399da3] Libdl
  [56ddb016] Logging
  [d6f4376e] Markdown
  [de0858da] Printf
  [3fa0cd96] REPL
  [9a3f8284] Random
  [ea8e919c] SHA
  [cf7118a7] UUIDs

(Pkg) pkg> activate
 Activating environment at `~/.julia/environments/v1.6/Project.toml`

(@v1.6) pkg>

It's as if you'd started Julia without the --project argument and then activated the current project, so when you do activate to deactivate the active project, it activates the default project, @v1.6.

[aviks]

So I was confused by this yesterday .. vscode starts the REPL with the home project in the current directory .. which probably makes sense (In Juno, you have to explicitly activate the primary project). But not having realised that, I found it very confusing why I could not get back to @1.3 by calling just activate. So I'd support this.. would have made the behaviour a little more discoverable.

[KristofferC]

Don't recall needing this much so just removing it probably makes sense.

[StefanKarpinski]

Ok, seems like there's general support, so I'll add a NEWS entry and then merge this.

[DilumAluthge]

Can we remove the const HOME_PROJECT prior to 2.0? Or will we need to wait until 2.0 to remove it?

[KristofferC]

This will break the Pkg tests so need to update there as well after this.

[StefanKarpinski]

Yeah, I have a PR to fix Pkg as well (just delete uses). Since it's not exported we can delete in 1.6 but I wanted to leave it so as not to break Pkg tests or cause tight coupling with this change and the necessary change in Pkg.

[StefanKarpinski]

NEWS added.

[StefanKarpinski]

Companion PR to remove all uses of HOME_PROJECT in Pkg: JuliaLang/Pkg.jl#1891; it also makes pkg> activate more useful by allowing it to activate the current project when there's no active project.

[jebej]

Same with IJulia which starts julia in the notebook dir, making it hard to go back to the root project.