# Import the same package after activating new environment
**URL:** https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749
**Category:** New to Julia
**Tags:** question
**Created:** [July 27, 2020, 8:58am UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749 "2020-07-27T08:58:24Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@evad](https://discourse.julialang.org/u/evad)
#### Post date: [July 27, 2020, 8:58am UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/1 "2020-07-27T08:58:24Z")
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.
1. Will it be the CSV@0.7.4 be used? or will it still bind to CSV in the user depot?
2. 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…
1. 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.
---
### Author:  [@evad](https://discourse.julialang.org/u/evad)
#### Post date: [July 27, 2020, 9:30am UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/2 "2020-07-27T09:30:46Z")
and CSV package in the two Project.toml has the same UUID: 
But showing different version when Pkg.status(“CSV”) in each environment…hmmmm
---
### Author:  [@hendri54](https://discourse.julialang.org/u/hendri54)
#### Post date: [July 27, 2020, 11:41am UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/3 "2020-07-27T11:41:52Z")
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
[https://docs.julialang.org/en/v1/manual/code-loading/#Environment-stacks-1](https://docs.julialang.org/en/v1/manual/code-loading/#Environment-stacks-1)
and
> [@Shared environments](https://discourse.julialang.org/t/shared-environments/35999/2):
>
> I think you will find this useful:
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.
---
### Author:  [@evad](https://discourse.julialang.org/u/evad)
#### Post date: [July 27, 2020, 12:59pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/4 "2020-07-27T12:59:44Z")
> 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?
---
### Author:  [@evad](https://discourse.julialang.org/u/evad)
#### Post date: [July 27, 2020, 1:15pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/5 "2020-07-27T13:15:43Z")
> [@hendri54](#):
>
> [Code Loading · The Julia Language](https://docs.julialang.org/en/v1/manual/code-loading/#Environment-stacks-1)
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`?
---
### Author:  [@evad](https://discourse.julialang.org/u/evad)
#### Post date: [July 27, 2020, 1:20pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/6 "2020-07-27T13:20:21Z")
And when execute `LOAD_PATH`, what does the following mean😂
```julia
3-element Array{String,1}:
"@"
"@v#.#"
"@stdlib"
```
2nd looks like the all the folders in `~/.julia/environments/`. Third is the standard library. What does first path `@` mean?
---
### Author:  [@hendri54](https://discourse.julialang.org/u/hendri54)
#### Post date: [July 27, 2020, 1:47pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/7 "2020-07-27T13:47:18Z")
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](https://lhendricks.org/julia_notes.pdf). Perhaps that reduces confusion a little.
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [July 27, 2020, 1:52pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/8 "2020-07-27T13:52:25Z")
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.
---
### Author:  [@laborg](https://discourse.julialang.org/u/laborg)
#### Post date: [July 27, 2020, 2:05pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/9 "2020-07-27T14:05:01Z")
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?
---
### Author:  [@evad](https://discourse.julialang.org/u/evad)
#### Post date: [July 27, 2020, 2:39pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/10 "2020-07-27T14:39:14Z")
> [@hendri54](#):
>
> It may be useful to read the section on package in [Notes on the Julia language](https://lhendricks.org/julia_notes.pdf). Perhaps that reduces confusion a little.
clear! thanks for pointing out this writeup!
---
### Author:  [@evad](https://discourse.julialang.org/u/evad)
#### Post date: [July 27, 2020, 2:41pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/11 "2020-07-27T14:41:03Z")
or rather is it recommended to fix working environment and load specific packages from Project.toml therein?
---
### Author:  [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [July 27, 2020, 2:46pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/12 "2020-07-27T14:46:51Z")
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).
---
### Author:  [@tbeason](https://discourse.julialang.org/u/tbeason)
#### Post date: [July 27, 2020, 3:28pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/13 "2020-07-27T15:28:24Z")
I restart Julia after any environment changes to avoid situations like this.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [July 30, 2020, 2:24pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/14 "2020-07-30T14:24:13Z")
> [@kristoffer.carlsson](#):
>
> 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.
I wonder if a warning about this would make sense in interactive sessions. Eg
```julia
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.
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [July 30, 2020, 2:26pm UTC](https://discourse.julialang.org/t/import-the-same-package-after-activating-new-environment/43749/15 "2020-07-30T14:26:32Z")
> [@Tamas\_Papp](#):
>
> Could not find an existing issue for this, sorry if I missed it.
>
>
> Imagine the following scenario: A user starts Julia in Juno (which loads a bunch… of dependencies into Julia at startup). They then activate their project and loads a package. If that package shares any dependencies with Juno, the versions of the dependencies Juno used will be used for the package. These versions might be completely incompatible with the current project and can lead to silent errors in the code running.
>
> Loading packages, changing project, and then loading more packages always have this risk but in the case where packages are loaded at startup, it might be hard to realize it is happening.
>
> It might, therefore, make sense to warn in the case where a package tries to load a dependency and code loading sees that the dependency with that UUID is already loaded but at a different version than in the current project.
>
> It could be argued that anyone that wants real reproducibility should run with a custom \`LOAD\_PATH\` to only have the current project as the entry but I think that is quite rare in practice.