Pre-activate hook? about conda-build HOT 8 CLOSED

One issue is supporting different shells from bash. And also Windows...

from conda-build.

Yup. It gets annoyingly more involved once you get past the surface.

We've (Continuum) talked in the past about implementing conda via bash/zsh scripts right? Perhaps that is the most appropriate top-level change to make. That would make this particular change trivial to implement.

A Windows equivalent... ugh. No technical reason why it wouldn't be possible.

from conda-build.

The problem is that right now, activate is really just a convenience script. All it does is prepend the PATH and set CONDA_DEFAULT_ENV (the latter lets you conda install in that environment without using -n). But there's no reason why you shouldn't be able to modify your PATH manually, or just call the absolute path to the binary. I personally have more than one conda environment in my default PATH.

So I'm a little uneasy about pre-activate scripts, because then packages that use them would only work if you used activate to activate the environment.

I think a better solution here would be to patch R to find tcl/tk automatically in the same prefix. We can also patch our tcl/tk if that helps (though we shouldn't change the tcl/tk API obviously).

from conda-build.

Oh, right, yeah I understand how the current implementation of activate works -- I was referring to the enhancement that's been thrown about a couple of times where conda would actually be implemented as a shell function, dispatching to underlying Python files where necessary.

That's a pretty substantial change though. Our installer would have to change, Linux/OSX users would have to ensure their dotfiles source the new whatever.rc files that we provide, etc. There are definitely benefits though -- implementing them directly in bash/zsh facilitates environment manipulation as well as vastly improved completion support (especially with zsh).

I guess R could be patched. I don't think this is unique to R though; some packages really do rely on environment variables being set correctly (ORACLE_HOME and QTDIR come to mind too) -- this is going to become more common as conda starts branching out into other non-Python arenas.

So, it would be great if conda had a facility for supporting this. (It's just unfortunate that the implementation details are so... complicated, once you dig past the surface layer.)

from conda-build.

That too would just be a convenience wrapper, so that you don't have to type "source". But using conda directly and modifying the PATH manually would still supported (especially since people do use non-bash shells like csh, zsh, fish, ...).

I really think it's not a question of implementation details. It's just a question of what we want to consider a conda environment to be. Right now, it is really nothing more than another prefix on your PATH. activate helps you manage your PATH, but that's it. This idea is really powerful. Imagine the possibilities if every single independent program on your computer used a different environment. Issues like conflicting libraries would be non-issues. You can already do this with Python programs using virtualenv or conda environments, but conda is Python agnostic, so you can really do it with anything. Conda's clever ideas of hard linking and relocatable packages make this possible.

So really the issue is packages like oracle or tk or qt that only expect to be installed once per machine, not a hundred times as conda lets you do. Applying your idea weakens the idea of any conda environment that uses it. Suddenly, they can only be used if they are activated (and of course only one environment can be active at once per (bash) session). It's almost as bad as the non-environment situation where you can only have one prefix per system.

I'm not opposed or for the idea at this point. I just think we should understand the implications.

(by the way, we already have tab completion support in bash using argcomplete. See http://conda.pydata.org/docs/config.html#tab-completion).

from conda-build.

I believe this is solved by conda-env, but maybe not documented well? https://github.com/conda/conda-env/blob/develop/bin/activate#L78

from conda-build.

activate.d scripts can be used for this. Closing.

https://conda.io/docs/using/envs.html#saved-environment-variables

from conda-build.

Hi there, thank you for your contribution!

This issue has been automatically locked because it has not had recent activity after being closed.

Please open a new issue if needed.

Thanks!

from conda-build.