Conda env vs venv / pyenv / virtualenv / etc
Question:
To add a question to the great question and discussion here on pyenv, venv, virtualenv, and virtualenvwrapper, could someone please explain how conda environments fit into this world? When are the preferred use cases for conda environments vs the other virtual environment options?
Answers:
Update 2021-0602: After researching, experiencing, and googling more I found this article. It is detailed, opinionated in what I found a helpful way, and provided everything I was looking for and more. Highly recommend. Conda is quite different from venv.
Original Answer
After researching and playing around, here’s what I’ve found, particularly focused on the difference between conda environments and venv:
- High level, there’s not that much of a difference between conda environments and venv. There are not large performance differences, time in setup differences, replication differences, etc.
- The decision to use one or the other should primarily by driven by personal preference, and the convention at work (e.g. if your work uses venv for everything, it probably makes sense to use venv and not conda environments.)
There are some differences worth calling out:
- Conda environments can set up environments for python and also R, so if you switch between the two conda is probably preferable so you only need to learn one set of tools/conventions.
- Conda environments all get stored in a single folder. This has pros and cons:
- Pro: you can easily look up all environments you’ve created.
- Pro: you can re-use one environment for multiple projects (e.g. I have a "finance" environment which works well for all my finance-related projects.)
- Con: you have to name all your environments differently, and remember the names (or look them up).
- Con: it is more of a pain to store that environment in the project folder you’ve created. This means you need to remember which environment goes with which project, and you can’t simply cd into the project folder and then activate the generically named ‘env’ that is stored in that folder.
For the type of programming I’m doing, I find conda environments helpful. I could easily see use cases where venv is the better choice.
Lastly, Conda is both an environments manager as well as a package manager like PIP. Useful comparison table here.
In short, if you don’t have a strong preference already, conda is more robust than venv or pip, can be combined with pip, and is probably the better default option. That said, if you already have a strong preference it means you likely already know how to do what you want, so it’s unlikely to be worth it to change.
You can also use (mini)conda to install not just different python versions (into different environments), but node.js, ruby, even postgresql, etc. It has more binary-compiled packages than venv (well, so-called wheels), You can definitely use it instead of pyenv and nvm and rvm, etc. The linked article to whiteboxml is really good in pinning down the differences.
I also tried it on windows extensively, and have to admit it works better than I thought. If something does not work out you can always use WSL2 or just switch to macos/linux.
To add a question to the great question and discussion here on pyenv, venv, virtualenv, and virtualenvwrapper, could someone please explain how conda environments fit into this world? When are the preferred use cases for conda environments vs the other virtual environment options?
Update 2021-0602: After researching, experiencing, and googling more I found this article. It is detailed, opinionated in what I found a helpful way, and provided everything I was looking for and more. Highly recommend. Conda is quite different from venv.
Original Answer
After researching and playing around, here’s what I’ve found, particularly focused on the difference between conda environments and venv:
- High level, there’s not that much of a difference between conda environments and venv. There are not large performance differences, time in setup differences, replication differences, etc.
- The decision to use one or the other should primarily by driven by personal preference, and the convention at work (e.g. if your work uses venv for everything, it probably makes sense to use venv and not conda environments.)
There are some differences worth calling out:
- Conda environments can set up environments for python and also R, so if you switch between the two conda is probably preferable so you only need to learn one set of tools/conventions.
- Conda environments all get stored in a single folder. This has pros and cons:
- Pro: you can easily look up all environments you’ve created.
- Pro: you can re-use one environment for multiple projects (e.g. I have a "finance" environment which works well for all my finance-related projects.)
- Con: you have to name all your environments differently, and remember the names (or look them up).
- Con: it is more of a pain to store that environment in the project folder you’ve created. This means you need to remember which environment goes with which project, and you can’t simply cd into the project folder and then activate the generically named ‘env’ that is stored in that folder.
For the type of programming I’m doing, I find conda environments helpful. I could easily see use cases where venv is the better choice.
Lastly, Conda is both an environments manager as well as a package manager like PIP. Useful comparison table here.
In short, if you don’t have a strong preference already, conda is more robust than venv or pip, can be combined with pip, and is probably the better default option. That said, if you already have a strong preference it means you likely already know how to do what you want, so it’s unlikely to be worth it to change.
You can also use (mini)conda to install not just different python versions (into different environments), but node.js, ruby, even postgresql, etc. It has more binary-compiled packages than venv (well, so-called wheels), You can definitely use it instead of pyenv and nvm and rvm, etc. The linked article to whiteboxml is really good in pinning down the differences.
I also tried it on windows extensively, and have to admit it works better than I thought. If something does not work out you can always use WSL2 or just switch to macos/linux.