Conda is an open source package management system and environment management system for installing multiple versions of software packages and their dependencies and switching easily between them. It works on Linux, OS X and Windows, and was created for Python programs but can package and distribute any software.
Conda is included in Anaconda and Miniconda. Conda is also included in the Continuum subscriptions of Anaconda, which provide on-site enterprise package and environment management for Python, R, Node.js, Java, and other application stacks. Conda is also available on pypi, although that approach may not be as up-to-date.
Miniconda is a small “bootstrap” version that includes only conda, Python, and the packages they depend on. Over 720 scientific packages and their dependencies can be installed individually from the Continuum repository with the “conda install” command.
Anaconda includes conda, conda-build, Python, and over 150 automatically installed scientific packages and their dependencies. As with Miniconda, over 250 additional scientific packages can be installed individually with the “conda install” command.
The conda command is the primary interface for managing Anaconda installations. It can query and search the Anaconda package index and current Anaconda installation, create new conda environments, and install and update packages into existing conda environments.
Presentations & Blog Posts¶
- python 2.7, 3.4, 3.5, or 3.6
What’s new in conda 4.3?¶
This release contains many improvements to performance, warning and error messages, and conda’s disk access, download, and package caching behavior. Also a noarch/universal type for python packages is now officially supported, a Python API module has been added, and the ‘r’ channel is now a default channel. The changelog contains a complete list of changes.
Unlink and Link Packages in a Single Transaction: This provides improved error recovery by ensuring that conda is safe, defensive and fault-tolerant whenever it changes data on disk.
Progressive Fetch and Extract Transactions: If errors are encountered while downloading packages, conda now keeps the packages that downloaded correctly and only re-downloads those with errors.
Generic- and Python-Type Noarch/Universal Packages: Along with conda-build 2.1.0, a noarch/universal type for python packages is now officially supported. These are much like universal python wheels. Files in a python noarch package are linked into a prefix just like any other conda package, with the following additional features:
- conda maps the
site-packagesdirectory to the correct location for the python version in the environment,
- conda maps the python-scripts directory to either
$PREFIX/Scriptsdepending on platform,
- conda creates the python entry points specified in the conda-build recipe, and
- conda compiles pyc files at install time when prefix write permissions are guaranteed.
Python noarch packages must be “fully universal.” They cannot have OS- or python version-specific dependencies. They cannot have OS- or python version-specific “scripts” files. If these features are needed, traditional conda packages must be used.
- conda maps the
Multi-User Package Caches: Package cache handling has been improved while preserving the on-disk package cache structure. Both writable and read-only package caches are fully supported.
Python API Module: The new
conda.cli.python_apimodule allows using conda as a Python library without needing to “shell out” to another Python process. There is also a
conda.exportsmodule for longer-term use of conda as a library across conda releases, although conda’s Python code is considered internal and private and is subject to change across releases. For now conda will not install itself into environments other than its original install environment.
Remove All Locks: Locking in conda had bugs and often created a false sense of security, and has been removed. The multi-user package caches in this release have improved safety by hard-linking packages in read-only caches to the user’s primary user package cache. However, undefined behavior can still result when conda is running in multiple processes and operating on the same package caches or the same environments.
Conda can now refuse to clobber existing files that are not within the unlink instructions of the transaction. The path_conflict configuration option can be set to
prevent. The current behavior and default in 4.3 is
clobber. The default in 4.4 will be
warn. The default in 4.5 and beyond will be
prevent. This can be overridden with the
--clobbercommand line flag.
Conda signed packages were vulnerable and created a false sense of security and have now been removed. Work has begun to incorporate The Update Framework into conda as a replacement.
Conda 4.4 will drop support for older versions of conda-build.
To verify that a channel URL is a valid conda channel, conda now checks that
noarch/repodata.json.bz2exist. The check does pass if one or both of these files exist but are empty.
A new “trace” log level with extremely verbose output, enabled with the
-v -v -vor
-vvvcommand-line flags, the
verbose: 3configuration parameter, or the
Conda can now be installed with pip, but only when used as a library or dependency.
The ‘r’ channel is now part of the default channels.
conda infonow shows user-agent, UID, and GID.
HTTP timeouts are configurable.
The conda home page is now updated to conda.io.
Fetch and extract for explicit URLs are now separate passes.
Vendor URLs are now parsed by urllib3.
Use of the Cache-Control max-age header for repodata is now implemented.
Conda now caches repodata locally without remote server calls and has a
Conda now has a
pkgs_dirsconfiguration parameter, an
Package resolution/solver hints have been improved with better messaging.
Further bug fixes, performance improvements, and better error and warning messages.
See the changelog for a complete list of changes.