

#Miniconda vs anaconda python install#
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. Installing Conda will enable you to create and remove python environments as you wish, therefore providing you with same functionality as virtualenv would.
#Miniconda vs anaconda python software#
However in software development, dropping in local, ephemeral, lightweight environments with virtualenv might be convenient. In my experience, conda fits well in a data science application and serves as a good general env tool. Cannon's blog post on How virtual environments work microvenv: pip-based venv (non-Windows).conda allows you to create environments with nearly any Python version. virtualenv creates environments using the same Python version it was installed with. Python is needed to install and run virtualenv, but conda already ships with Python.However, both have a mechanism to create a file of pinned packages. Sadly neither has an official lock file, so reproducing environments has not been solid with either tool.PyPI works with both tools through pip, but conda can add additional channels, which can sometimes install faster.In contrast, conda's environments are global and saved in one place. virtualenv creates project-specific, local environments usually in a.Moreover, if you wish to transfer your preserved state of an environment, you can do so by sharing or cloning an env.Ī non-exhaustive, quick look at features from each tool: In my experience, conda is faster and more reliable at installing large libraries such as numpy and pandas. As of Anaconda 4.1, nbextensions were added, adding extensions to notebooks more easily. In addition, installing ipykernel in an environment adds a new listing in the Kernels dropdown menu of Jupyter notebooks, extending reproducible environments to notebooks. 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.

In an activated environment, install packages via conda or pip: (envname)> conda install I will add that creating and removing conda environments is simple with Anaconda.

It's still awkward to make a local directory install with conda. 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 :)ĮDIT: I reviewed the situation again in 04/2021 and it is unchanged. You can fix that by giving it a name, but virtualenv does the right thing by default. 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.įinally, 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. 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. 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 former (centralized) makes sense if you are e.g. 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. I use both and (as of Jan, 2020) they have some superficial differences that lend themselves to different usages for me.
