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, …).
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.
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:
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?
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.
...
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.
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.
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).
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
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.
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
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.
