Does Conda replace the need for virtualenv?

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.

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 preserved state of an environment, you can do so by sharing or cloning an env.

---

Comparisons

A non-exhaustive, quick look at features from each tool:

Description

• virtualenv creates project-specific, local environments usually in a .venv/ folder per project. In contrast, conda‘s environments are global and saved in one place.
• PyPI works with both tools through pip, but conda can add additional channels, which can sometimes install faster.
• Sadly neither has an official lock file, so reproducing environments has not been solid with either tool. However, both have a mechanism to create a file of pinned packages.
• Python is needed to install and run virtualenv, but conda already ships with Python. virtualenv creates environments using the same Python version it was installed with. conda allows you to create environments with nearly any Python version.

See Also

• venv: in the Standard Library
• virtualenvwrapper: global virtualenv
• pyenv: manage python versions
• mamba: "faster" conda
• microvenv: pip-based venv (non-Windows)
• B. Cannon’s blog post on How [non-conda] virtual environments work

In my experience, conda fits well in a data science application and serves as a good general env tool. However in software development, dropping in local, ephemeral, lightweight environments with virtualenv might be convenient.

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

Installing Conda will enable you to create and remove python environments as you wish, therefore providing you with same functionality as virtualenv would.

In case of both distributions you would be able to create an isolated filesystem tree, where you can install and remove python packages (probably, with pip) as you wish. Which might come in handy if you want to have different versions of same library for different use cases or you just want to try some distribution and remove it afterwards conserving your disk space.

Differences:

License agreement. While virtualenv comes under most liberal MIT license, Conda uses 3 clause BSD license.

Conda provides you with their own package control system. This package control system often provides precompiled versions (for most popular systems) of popular non-python software, which can easy ones way getting some machine learning packages working. Namely you don’t have to compile optimized C/C++ code for you system. While it is a great relief for most of us, it might affect performance of such libraries.

Unlike virtualenv, Conda duplicating some system libraries at least on Linux system. This libraries can get out of sync leading to inconsistent behavior of your programs.

Verdict:

Conda is great and should be your default choice while starting your way with machine learning. It will save you some time messing with gcc and numerous packages. Yet, Conda does not replace virtualenv. It introduces some additional complexity which might not always be desired. It comes under different license. You might want to avoid using conda on a distributed environments or on HPC hardware.

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

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 🙂

EDIT: I reviewed the situation again in 04/2021 and it is unchanged. It’s still awkward to make a local directory install with conda.

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.

1.No, if you’re using conda, you don’t need to use any other tool for managing virtual environments (such as venv, virtualenv, pipenv etc).
Maybe there’s some edge case which conda doesn’t cover but virtualenv (being more heavyweight) does, but I haven’t encountered any so far.

---

2.Yes, not only can you still use pip, but you will probably have to. The conda package repository contains less than pip’s does, so conda install will sometimes not be able to find the package you’re looking for, more so if it’s not a data-science package.
And, if I remember correctly, conda’s repository isn’t updated as fast/often as pip’s, so if you want to use the latest version of a package, pip might once again be your only option.

Note: if the pip command isn’t available within a conda virtual environment, you will have to install it first, by hitting:

conda install pip

Conda has a better API no doubt. But, I would like to touch upon the negatives of using conda since conda has had its share of glory in the rest of the answers:

1. Solving environment Issue – One big thorn in the rear end of conda environments. As a remedy, you get advised to not use conda-forge channel. But, since it is the most prevalent channel and some packages (not just trivial ones, even really important ones like pyspark) are exclusively available on conda-forge you get cornered pretty fast.

2. Packing the environment is an issue

There are other known issues as well. virtualenv is an uphill journey but, rarely a wall on the road. conda on the other hand, IMO, has these occasional hard walls where you just have to take a deep breath and use virtualenv