Comments (8)
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.
Related Issues (20)
- Conda build is stuck with some unrelated build aterfacts. Unable to purge them.
- Limit logging config to CLI
- Deprecate `noarch_python_build_age` MetaData/Config setting
- the MSYS2 prefixes in the cran skeleton are fixed
- InvalidSpec error for spec ">=0.4,<0.4.4" in sktime HOT 8
- setup.py build documentation/implemantation for windows uses deprecated python setup.py install HOT 2
- Improve `cbc.yml` error reporting and validation
- Release 24.5.x
- Undefined environment variables are redefined in build script environment for multi-output builds
- Default Perl variant for cpan skeleton is enforcing a default version in a clean system
- Permissions of `info/*` files are not adjusted
- `meta.yaml` accepts negative build numbers HOT 1
- `conda-build --channel CHANNEL --override-channels` always includes the "default" channel HOT 1
- Publish stable artifacts with checksums during release HOT 2
- Cross compiling with virtual packages HOT 2
- `conda-build` version `24.5.0` assigns values to `frozendict` keys: results in internal errors HOT 3
- BUG: noarch package in multi-output recipe changes CPU architecture mid-build HOT 4
- add `conda mambabuild` subcommand to aid transitioning away from `boa` HOT 10
- add `git` to the `build` dependencies automatically when `git_rev` or `git_url` is used in `source:`
- Adding conda-build in an environment breaks conda info HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from conda-build.