Does Conda replace the need for virtualenv?

Question

I recently discovered Conda after I was having trouble installing SciPy, specifically on a Heroku app that I am developing.

With Conda you create environments, very

Answer 1

Short answer is, you only need conda.

1. Conda effectively combines the functionality of pip and virtualenv in a single package, so you do not need virtualenv if you are using conda.

2. You would be surprised how many packages conda supports. If it is not enough, you can use pip under conda.

Here is a link to the conda page comparing conda, pip and virtualenv:

https://docs.conda.io/projects/conda/en/latest/commands.html#conda-vs-pip-vs-virtualenv-commands.

Answer 2

Virtual Environments and pip

I will add that creating and removing conda environments is simple with Anaconda.

> conda create --name <envname> python=<version> <optional dependencies>

> conda remove --name <envname> --all 

In an activated environment, install packages via conda or pip:

(envname)> conda install <package>

(envname)> pip install <package>

These environments are strongly tied to conda's pip-like package management, so it is simple to create environments and install both Python and non-Python packages.

---

Jupyter

In addition, installing ipykernel in an environment adds a new listing in the Kernels dropdown menu of Jupyter notebooks, extending reproducible environments to notebooks. As of Anaconda 4.1, nbextensions were added, adding extensions to notebooks more easily.

Reliability

In my experience, conda is faster and more reliable at installing large libraries such as numpy and pandas. Moreover, if you wish to transfer your the preserved state of an environment, you can do so by sharing or cloning an env.

Answer 3

I use both and (as of Jan, 2020) they have some superficial differences that lend themselves to different usages for me. By default Conda prefers to manage a list of environments for you in a central location, whereas virtualenv makes a folder in the current directory. The former (centralized) makes sense if you are e.g. doing machine learning and just have a couple of broad environments that you use across many projects and want to jump into them from anywhere. The latter (per project folder) makes sense if you are doing little one-off projects that have completely different sets of lib requirements that really belong more to the project itself.

The empty environment that Conda creates is about 122MB whereas the virtualenv's is about 12MB, so that's another reason you may prefer not to scatter Conda environments around everywhere.

Finally, another superficial indication that Conda prefers its centralized envs is that (again, by default) if you do create a Conda env in your own project folder and activate it the name prefix that appears in your shell is the (way too long) absolute path to the folder. You can fix that by giving it a name, but virtualenv does the right thing by default.

I expect this info to become stale rapidly as the two package managers vie for dominance, but these are the trade-offs as of today :)

Answer 4

Another new option and my current preferred method of getting an environment up and running is Pipenv

It is currently the officially recommended Python packaging tool from Python.org

Answer 5

I work in corporate, behind several firewall with machine on which I have no admin acces

In my limited experience with python (2 years) i have come across few libraries (JayDeBeApi,sasl) which when installing via pip threw C++ dependency errors error: Microsoft Visual C++ 14.0 is required. Get it with "Microsoft Visual C++ Build Tools": http://landinghub.visualstudio.com/visual-cpp-build-tools

these installed fine with conda, hence since those days i started working with conda env. however it isnt easy to stop conda from installing dependency inside c.programfiles where i dont have write access.

Answer 6

Yes, conda is a lot easier to install than virtualenv, and pretty much replaces the latter.