I asked this because I have CSV@0.6.2 installed in the user depot and have it imported. Then I created a new project folder, activated it and installed another version of CSV@0.7.4. Now in REPL typing import CSV.
Will it be the CSV@0.7.4 be used? or will it still bind to CSV in the user depot?
Is there a way to check which CSV is currently imported?
Then I tried to import a package not in the current folder’s project.toml, say Primes [installed in user depot], and succeeded…
What is the right way to limit Julia to use packages defined in current folder’s project.toml?
And lastly, the reason I did the above, is that I can’t figure out a way to upgrade CSV to V0.7.4 in the user depot due to incompatibility with other packages. So what is the correct way to make sure CSV upgrade to the latest version and other dependent packages get resolved as well (either upgrade or downgrade to appropriate versions).
A bit long but I’m quite confused reading the official manual about what happens when “import X” in Julia.
The version of the package is determined at the time of Pkg.add. import or using just gets its version from Manifest.toml.
In your case, in the REPL you will get 0.6.2 – which is really saying: in the v1.4.2 environment (or whatever your version is), this is what you will get.
In the other environment, Manifest.toml points to 0.7.4, so that’s what you will get. Except that you are actually in a stacked environment (where the dependencies of v1.4.2 and other are both available. My understanding is that the most recently activated environment wins in this case (so you should get 0.7.4). See
But if you start Julia, issue using CSV, then activate other and try using CSV again, you are stuck with the version that’s already loaded.
pkg> st shows the package versions resolved in the current environment.
The reason why you could load Primes is likely a stacked environment as well. If it isn’t in the Manifest.toml for a package you activate in this session, you cannot load it.
As for upgrading: you don’t upgrade what’s in the depot. You upgrade what is in the current environment’s Manifest.toml. So, pkg> up CSV in other changes the version in other but nowhere else.
If it isn’t in the Manifest.toml for a package you activate in this session, you cannot load it.
Primes is not in Manefest.toml file of my activated environment, but I can execute using Primes, which I guess it is loaded from user depot.
As for upgrading: you don’t upgrade what’s in the depot.
I usually do a ]up in the user depot. But for some reason the CSV is not the latest version. I want to force it upgrade to the latest version. Is there a reason why I don’t do it?
I read this and got confused. Like the last sentence:
A call to Pkg.add("X") will add to the appropriate project and manifest files, selected via Pkg.activate("Y") , so that a future call to import X will load X without further thought.
I suppose each time when launching julia, I need to activate the “Y” environment first, so that call to import X will load X from “Y”? If I don’t activate first, will it still load the user depot X?
The key concept here is an environment. One environment is always active. It’s the one shown by the pkg> prompt.
when you start Julia (unless you use certain command line switches) you activate the vX.X environment. Adding a package (or updating or resolve etc) essentially edits Project/Manifest.toml for that environment.
When you say you “usually ]up in the user depot” – well it doesn’t work that way. The depot contains all versions of all packages ever used (and not garbage collected due to unuse for some time). If you look inside packages in the depot dir, you will actually find copies of the package code.
If you want to work in project “Y”, then indeed you need to activate “Y” each time after starting Julia. Otherwise, the toml files from vX.X will be used to resolve dependencies.
I think the first entry in LOAD_PATH is Base.
It may be useful to read the section on package in Notes on the Julia language. Perhaps that reduces confusion a little.
Only one instance of a package can ever be loaded in a Julia session. The version you load the first time is what will be used. It doesn’t matter if you change the environment and then try to reload the package. It is therefore discouraged to change environments after loading some packages.
It might be a nice educational message to inform the user if he/she tries to load a package that has already been loaded in a different version. (e.g. “Not using XYZ in version 7.2, because XYZ has already been loaded in version 6.4”). Or would this be considered to noisy?
My suggestion recommendation is to never manipulate the environment and the stack during runtime – set it up first and then run code (including using/import statements).
I wonder if a warning about this would make sense in interactive sessions. Eg
pkg> status Foo
Status `~/.julia/environments/v1/Project.toml`
[deadbeef] Foo v0.1.0
julia> using Foo
pkg> add Foo@0.2
julia> using Foo
Warning: Manifest specifies a version different version for Foo which is
already loaded. Restart your Julia session to use that version.
Could not find an existing issue for this, sorry if I missed it.