Julia is missing the deactivate command

When using julia on my enviroment /home/johnsmith/julia

If I want to start a new project say ProjectA, I would create the directory

/home/johnsmith/julia/project/projectA

then active it using the command

julia>]
(v1.0) pkg> activate /home/johnsmith/julia/project/projectA

Now after I finished with projectA for the time being, and want to get back to normal, the following command does not work

(v1.0) pkg>  deactivate /home/johnsmith/julia/project/projectA

So how do I get back to the state I was in before I activate projectA?

1 Like

Just use activate with no argument

pkg> activate

What made you think there was a deactivate command?

11 Likes

For what it’s worth, there is an activate and a deactivate command in Conda/Python.
I find it better from a discoverability point of view, as most commands tends to have an opposite one (apt install/remove, Pkg.add/Pkg.rm, …).

5 Likes

Think of activate in Julia as cd in the terminal. Just like cd takes you back to your home directory, activate takes you to your home project.

21 Likes

Would it not be better if julia has a deactivate command which does not take any argument or ignores any arguments and all it does is an alias for activate with no arguments?

This would make it simple for learners to grasp the concept.

If you go through the documentation of Julia in the eyes of a newbie, see if you can figure out that the command activate with no argument is the same as deactivate.

8 Likes

If you think the documentation is can be improved, please open an issue or (ideally) make a PR. It is undeed true that the documentation does not give an example for pkg> activate without arguments, so that could be remedied. Somewhat related:

1 Like

I came across this because I reached for “deactivate” before trying “activate” without any arguments.

Seems like having “deactivate” be an alias for this would make things easier on the user. And as we have discussed before, the pkg command line is intended to be more intuitive/do-what-I-mean, yes?

Is there a reason to not have “deactivate”?

2 Likes

I don’t know how the status was when this was written but now

help?> Pkg.activate
  Pkg.activate([s::String]; shared::Bool=false)

...

  If no argument is given to activate, then activate the home project. The home project is specified by either the --project command line option to the julia executable, or the
  JULIA_PROJECT environment variable.

  Examples
  ≡≡≡≡≡≡≡≡≡≡

  Pkg.activate()
  Pkg.activate("local/path")
  Pkg.activate("MyDependency")
(v1.3) pkg> ?activate
  activate
  activate [--shared] path

  Activate the environment at the given path, or the home project environment if no path is specified. 
...
3 Likes

I think this was about the docs, not the docstrings, but even there I am mistaken, since this has been part of Pkg since

https://github.com/JuliaLang/Pkg.jl/pull/1023

2 Likes

I think it should be added in the document. Most users check the document for new command. It takes me some time to get the answer here rather than the document.

https://docs.julialang.org/en/v1/stdlib/Pkg/index.html

The docstrings are included in the documentation, too:

https://julialang.github.io/Pkg.jl/dev/api/#Pkg.activate

While true I think our documentation is still not as good as it could be. I think the relevant sentence

If no argument is given to activate , then activate the home project. The home project is specified by either the --project command line option to the julia executable, or the JULIA_PROJECT environment variable.

could be confusing for a beginner. What if I neither started Julia with --project nor set the JULIA_PROJECT environment variable and do ] activate? It’s not clear from the docstring what will happen in this case.

Also, note the use of the term “home project”. I reckon the difference between “home project” and “default project” (v1.x) is subtle to a beginner who, again, likely hasn’t specified a “home project”. In this context, let me also mention that the “default project” (v1.x) - which by default is equal to the “home project” - is special in the sense that it is (by another default) also the “global project”. A fact which is also not as clear from the documentation as it could be (you have to read about the LOAD_PATH to understand this, an advanced concept in my opinion).

As has been discussed on Slack at some point (@davidanthoff) I personally think that the “default project” shouldn’t be equal to the “global environment” (the one which automatically is in the LOAD_PATH) to begin with. I’d like extra syntax like ] add --global MyPackage for adding a package to a separate global environment. This way, confusions like this one, which came up just yesterday, could be easily avoided.

In any case, I think that the Pkg documentation in its entirety explains almost all features/mechanisms, but individual sections can be pretty confusing without reading the rest of the docs. I think we can do better and I hope to find the time to make a few PRs soon.

8 Likes

Just to make you point: half of what you just said was news to me. There is a “home project” that is different from the “default project”?!

1 Like

The “home project” is what you specify through --project or JULIA_PROJECT. By default, that is if you havent specified either, “home project” === “default project” (v1.x).

See what happens on ] activate after

  • starting julia with julia and ] activate .
  • starting julia with julia --project=.

The first one will bring you back to the home (=== default) project, v1.x. The second will bring you back to the home project == local project (you’re already there so nothing will happen).

5 Likes

That would be great. I think this is not only a question of documenting these concepts well, but also providing examples of how people typically use them in their workflow. The workflow section

https://docs.julialang.org/en/v1/manual/workflow-tips/

could also benefit from a Pkg-centric rewrite.

4 Likes

I encountered an issue where this doesn’t work as expected.

At least in the VSCode REPL, it will default to the package directory. But ]activate alone does not cause it to drop back to the main Julia environment @1.5. Instead it stays on the package directory.

What is the command to load the global default environment if you’re “stuck” in the local project?

In my case, I want to load a temporary package like BenchmarkTools without worrying about it going into my Project.toml.

1 Like
activate --shared v1.5

However, I think @StefanKarpinski had plans on changing this so that activate always brings you back to the v1.x environment.

3 Likes

There’s a PR: https://github.com/JuliaLang/Pkg.jl/pull/1891. I plan on finishing it up for 1.6, just need to fix the tests that the API change broke and merge it. If anyone wants to help, they’re welcome to fix the tests :grin:

3 Likes

After reading this thread and the docs, I do have a question, which I hope I will be forgiven for asking here: Does starting up Julia necessarily activate a default environment?

And if that’s the case, then to “deactivate” it, I can just activate some/any other environment? I’m not trying to be pedantic about the wording, it’s just that I want to make sure that Pkg.activate(; temp=true) will safely take me out of the previous environment once and for all. Thanks.

No, by default you have no active environment (in the sense of Pkg.activate). Perhaps what is `@.` in Julia `--project` command line option? - Stack Overflow clarifies things a bit.

3 Likes