conda environment activation

[csoja]

The user can now select a conda environment for use as the default python interpreter, but it seems this environment is not activated. This is an important feature of conda environments - as in this activation step other environment variables may be set.

https://conda.io/docs/user-guide/tasks/manage-environments.html#saving-environment-variables

Are there any plans to support conda environment activation?

[brettcannon]

Are you after a command to simply launch a terminal with the environment activated? Or are you wanting a way to run all processes through an activated conda environment? For the former that is doable if we ever provide a command to open an activated terminal. For the latter, though, we launch through your shell which means we would have to activate the environment every single time we ran a Python command.

We do support .env files to specify environment variables, but it looks like conda has a generic activated.d directory where all the shell files in that directory get run which is a bit fancier. A workaround would be to have a .env which gets sourced by a script in activate.d, but I suspect you are after a solution that will work with a conda environment as-is and without launching VS Code explicitly from an activated conda environment.

[goanpeca]

Are you after a command to simply launch a terminal with the environment activated?

Hi @brettcannon I guess this would be an initial step that would make things easier? To illustrate this I attach an image

So option 1 would be having an environment run the activate command if it is a conda python interpreter in this case?

Or are you wanting a way to run all processes through an activated conda environment?

all processes means in this case linting and the like for the python extensions? or something additional?

I guess eventually a user might want/need to have all these extra tools installed on a specific env (by default?)

[brettcannon]

Yeah, it's tricky to be clear in all of this since we execute Python in various scenarios. 😄 If you're simply after making sure we pass strings that get executed in the terminal to be in an activated situation then we can consider making that work. There's also the environment where the tooling like Pylint and Jedi that we integrate with runs in, and that's much trickier.

[goanpeca]

If you're simply after making sure we pass strings that get executed in the terminal to be in an activated situation then we can consider making that work.

I would say this would be the first easy step to make sure things work as expected out of the box for users. So 👍

I am using VSCode for some weeks now and having that in the workflow would really tidy up things.

There's also the environment where the tooling like Pylint and Jedi that we integrate with runs in, and that's much trickier.

Yeah I have seen that (some envs hidden on some user dotted dires :-p) , I think that initially it would not be necessary but eventually users do need to have linting tools be installed in their environments as python version affects how these tools work. How is VScode handling the 2.7/3.x differences for some of these tools?

---

I am looking for a simple example of how UX could break badly if the activation is not executed prior to running some python script.

Any canonical description of such scenarios :-p ?

Cheers

[brettcannon]

It's not an issue of breaking UX if we do activate the environment, it's having to manage the environments on our end appropriately and making simply work reasonably. For example, the API provided to us by VS Code for sending commands to a terminal is nothing more than one to send in a string to execute with no return value. So we have no idea if the environment is done activating and ready for receive input when we send the string in. If it isn't ready it just gets dropped.

And in the case of tooling, we would have to make sure that in all instances when conda happens to be involved we are using some multi-command to activate the environment and then execute the command through execv*() or what have you as this doesn't affect virtual environments.

IOW we understand why you want this, it's just not a simple one-line change to make it happen immediately no matter how simple it might seem from the outside. 😉 But we have started to discuss how we can solve this for conda and virtual environments in the simple case to start.

As for Python 2/3, there's no real issue for us since we either use ${python interpreter} -m ${tool} or you hard-code the path to the tool's CLI in your configuration.

[msarahan]

Just to add a use-case for something that will not currently work without activation, consider GDAL, which is a foundational package for geospatial data analysis. GDAL depends on an environment variable being set to the location of the GDAL DLL. We do this with activation scripts. When activation is not run, users will complain in ways like conda/conda#4050

We have discussed having conda set variables in a different way from arbitrary shell scripts - perhaps in new metadata that could be stored in the package's metadata. I expect that such development would help improve the situation with VS code, but unfortunately we don't have anything currently under development.

[DonJayamanne]

@csoja @brettcannon @msarahan @goanpeca
Launching an activated terminal for Conda and Virtual Environments will be tracked in #383
I'd like to move the discussion of creating activated terminals to that issue.