notes regarding env stacking, etc.

[ngam]

Because we are essentially relying on activate scripts, we only really activate the stacking and env/depot specification when the conda env is actually activated (conda activate env). Otherwise, the julia binary will still default back to the upstream behavior.

Triggering julia directly without activating conda env yields @v1.7:

ngam@t450:~$ /home/ngam/.Mambaforge-Linux-x86_64/envs/cenv/bin/julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.7.2 (2022-02-06)
 _/ |\__'_|_|_|\__'_|  |  https://github.com/conda-forge/julia-feedstock
|__/                   |

(@v1.7) pkg> 

After activating the conda env, it works correctly:

ngam@t450:~$ mamba activate cenv
(cenv) ngam@t450:~$ /home/ngam/.Mambaforge-Linux-x86_64/envs/cenv/bin/julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.7.2 (2022-02-06)
 _/ |\__'_|_|_|\__'_|  |  https://github.com/conda-forge/julia-feedstock
|__/                   |

(@cenv) pkg> 

This could be a problem in some situations. An example is using VSCode. VSCode will happily activate a conda env for you, if provided with a python interpreter. It will also do the same for julia, given a specific path. However, if one triggers julia's REPL, they may get this confusion:

source /home/ngam/.Mambaforge-Linux-x86_64/bin/activate
conda activate cenv
julia> source /home/ngam/.Mambaforge-Linux-x86_64/bin/activate
ERROR: syntax: invalid identifier name "."
Stacktrace:
 [1] top-level scope
   @ none:1

julia> conda activate cenv
ERROR: syntax: extra token "activate" after end of expression
Stacktrace:
 [1] top-level scope
   @ none:1

julia> 

We should perhaps consider solidifying these settings without having to use activation scripts. Another problematic situation is when you have two conda environments with two separate julia installations (say 1.7 and 1.8). Then, you would get this perhaps unexpected behavior:

(test) ngam@t450:~$ mamba activate devj
(devj) ngam@t450:~$ 
(devj) ngam@t450:~$ /home/ngam/.Mambaforge-Linux-x86_64/envs/cenv/bin/julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.7.2 (2022-02-06)
 _/ |\__'_|_|_|\__'_|  |  https://github.com/conda-forge/julia-feedstock
|__/                   |

(@devj) pkg> 
(devj) ngam@t450:~$ julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.9.0-DEV.140 (2022-03-04)
 _/ |\__'_|_|_|\__'_|  |  HEAD/c2524fd89* (fork: 1 commits, 1 day)
|__/                   |

(@devj) pkg>

The julia in ...cenv/bin/julia is activating a julia env called devj because the activation scripts in devj (which is activated) get called. Note the julia associated with devj is actually 1.9.0-DEV in this case.

[mkitti]

I'm not clear if any of the above is really unexpected except for vscode trying to activate a conda environment via the Julia REPL.

Does the Python interpreter act any differently in these situations?

[mkitti]

In VSCode, I usually open folders and have VSCode set the project to the thr folder I opened.

[ngam]

Does the Python interpreter act any differently in these situations?

I don't think so.

I'm not clear if any of the above is really unexpected...

Maybe more like unintended in the case of trying to use the julia binary outside the confines of the conda env --- which is, admittedly, a very edge case.

In my mind, it may be worthy to try to solidify this further such that .../envs/cenv/bin/julia will always start with @cenv and .../envs/devj/bin/julia will always start with @devj. Do you have any thoughts about this or would you rather have it be flexible (as it is currently designed)?

I am not sure how we would achieve that exactly, just thinking out loud.

[mkitti]

I do not see a precedent for the location of the executable to influence the environment or the depot location. If you want to use another conda environment, activate it.

If needed, I think one can start VSCode from within a conda environment. Also if one is using vscode, one probably should not be using the default project anyways.

If you are writing new code, then that project should have its own Project.toml and Manifest.toml.

[ngam]

I think what you're saying makes sense. I wanted to document this behavior to ensure we are on the same page when it comes to how this behaves in real life.

If you want to use another conda environment, activate it.

Yes, this is the assumed behavior. You don't want to trigger stuff from the conda env without activating it.

If needed, I think one can start VSCode from within a conda environment. Also if one is using vscode, one probably should not be using the default project anyways.

I don't know about this. I will try to see dig deeper into how the interpreters clash (i.e. due to the slight delay of activating a conda env). But yes, I wouldn't worry too much about this for now. Btw, it also only happens if one does Julia: Start REPL from the command prompt (cmd + shift + P on macOS) but it would work smoothly enough if one just starts the REPL from vscode's terminal window (i.e. by typing julia)

Closing for now since I believe we believe we should leave the behavior as is for now. Feel free to reopen.