Creating Python Virtual Environments with Conda: Why and How
heartbeat.fritz.ai
heartbeat.fritz.ai
Why not just use pip?
I'm not entirely convinced that's a good thing, but it's an easy path to managing those sorts of libraries alongside your Python libs.
Binder (https://mybinder.org/) is a good example of how well this can work - anyone can reproduce your work using e.g. Jupyter hosted on a binder, build from a conda env.
- Conda to manage multiple python versions on 1 box:
$ conda create -n env27 python=2.7
$ conda create -n env37 python=3.7
- Pip to manage packages in the environment: $ source activate env27
$ pip install -r requirements_27.txtI first tried using pip under a venv to install it, and I ran into dependency hell. I needed various dev libs and build-essential on my ubuntu box and I ultimately couldn't get it to compile llvmlite correctly (linker issuers and way too many LLVM versions).
I finally gave up and tried miniconda on a fresh box per some advice here on HN. I simply installed it, ran "conda create -n myenv fastparquet" and it just worked first try. No extra effort involved.
It seems less valuable if the prefix is hard coded to the specific user. To a lesser extent even specifying the name may be too limiting.
Ideally I would set the prefix for Conda for myself only once (~/.condarc?) and the source controlled config file would then extend that config.
I would expect the conda config file in a project to say nothing at all about the prefix unless it is relative to an existing prefix I set elsewhere.
This way I don't have to manipulate my environment and edit config files every time I run conda.
I should probably just RTFM.
Also, you can use pip to install software if you have the anaconda distribution installed. As far as I know it does not work the other way around.
Anything that is on the front-page is by definition front-page worthy otherwise it wouldn't have made its way there.