As the year winds down it’s time to say out with the old and in with the new. Well, conda is no different. What does conda 4.4 have in store for you?
Say goodbye to “source activate” in conda. That is so 2017. With conda 4.4 you can snappily “conda activate” and “conda deactivate” your conda environments. And that’s just the start! Read on to learn about other new features.
To get conda 4.4 right now, run
$ conda config --add channels conda-canary
$ conda update conda
$ conda config --system --add pinned_packages conda-canary::conda
With the release of conda 4.4, we recommend a change to how the
conda command is made available to your shell environment. All the old methods still work as before, but you’ll need the new method to enable the new
conda activate and
conda deactivate commands.
For the “Anaconda Prompt” on Windows, there is no change.
For Bourne shell derivatives (bash, zsh, dash, etc.), you likely currently have a line similar to
~/.bashrc file (or
~/.bash_profile file on macOS). The effect of this line is that your base environment is put on PATH, but without actually activating that environment. (In 4.4 we’ve renamed the ‘root’ environment to the ‘base’ environment.) With conda 4.4, we recommend removing the line where the
PATH environment variable is modified, and replacing it with
conda activate base
In the above, it’s assumed that
/opt/conda is the location where you installed miniconda or Anaconda Distribution. It may also be something like
For system-wide conda installs, to make the
conda command available to all users, rather than manipulating individual
~/.bash_profile) files for each user, just execute once
$ sudo ln -s /opt/conda/etc/profile.d/conda.sh /etc/profile.d/conda.sh
This will make the
conda command itself available to all users, but conda’s base (root) environment will not be activated by default. Users will still need to run
conda activate base to put the base environment on PATH and gain access to the executables in the base environment.
After updating to conda 4.4, we also recommend pinning conda to a specific channel. For example, executing the command
$ conda config --system --add pinned_packages conda-canary::conda
will make sure that whenever conda is installed or changed in an environment, the source of the package is always being pulled from the
conda-canary channel. This will be useful for people who use
conda-forge, to prevent conda from flipping back and forth between 4.3 and 4.4.
New Feature Highlights
- conda activate: The logic and mechanisms underlying environment activation have been reworked. With conda 4.4,
conda deactivateare now the preferred commands for activating and deactivating environments. You’ll find they are much more snappy than the
source deactivatecommands from previous conda versions. The
conda activatecommand also has advantages of (1) being universal across all OSes, shells, and platforms, and (2) not having path collisions with scripts from other packages like python virtualenv’s activate script.
- constrained, optional dependencies: Conda now allows a package to constrain versions of other packages installed alongside it, even if those constrained packages are not themselves hard dependencies for that package. In other words, it lets a package specify that, if another package ends up being installed into an environment, it must at least conform to a certain version specification. In effect, constrained dependencies are a type of “reverse” dependency. It gives a tool to a parent package to exclude other packages from an environment that might otherwise want to depend on it.
Constrained optional dependencies are supported starting with conda-build 3.0 (via [conda/conda-build#2001[(https://github.com/conda/conda-build/pull/2001)). A new
run_constrainedkeyword, which takes a list of package specs similar to the
runkeyword, is recognized under the
meta.yaml. For backward compatibility with versions of conda older than 4.4, a requirement may be listed in both the
run_constrainedsection. In that case older versions of conda will see the package as a hard dependency, while conda 4.4 will understand that the package is meant to be optional. Optional, constrained dependencies end up in
constrainskeyword, parallel to the
dependskeyword for a package’s hard dependencies.
- enhanced package query language: Conda has a built-in query language for searching for and matching packages, what we often refer to as
MatchSpec. The MatchSpec is what users input on the command line when they specify packages for
removeoperations. With this release, MatchSpec (rather than a regex) becomes the default input for
conda search. We have also substantially enhanced our MatchSpec query language. For example,
conda install conda-forge::python
is now a valid command, which specifies that regardless of the active list of channel priorities, the python package itself should come from the
conda-forgechannel. As before, the difference between
python==3.5is that the first contains a “fuzzy” version while the second contains an exact version. The fuzzy spec will match all python packages with versions >
3.6. The exact spec will match only python packages with version
22.214.171.124, etc. The canonical string form for a MatchSpec is thus
which should feel natural to experienced conda users. Specifications however are often necessarily more complicated than this simple form can support, and for these situations we’ve extended the specification to include an optional square bracket
component containing comma-separated key-value pairs to allow matching on most any field contained in a package’s metadata. Take, for example,
conda search 'conda-forge/linux-64::*[md5=e42a03f799131d5af4196ce31a1084a7]' --info
which results in information for the single package
cytoolz 0.8.2 py35_0
file name : cytoolz-0.8.2-py35_0.tar.bz2
name : cytoolz
version : 0.8.2
build string: py35_0
build number: 0
size : 1.1 MB
arch : x86_64
platform : Platform.linux
license : BSD 3-Clause
subdir : linux-64
url : https://conda.anaconda.org/conda-forge/linux-64/cytoolz-0.8.2-py35_0.tar.bz2
md5 : e42a03f799131d5af4196ce31a1084a7
- python 3.5*
- toolz >=0.8.0
The square bracket notation can also be used for any field that we match on outside the package name, and will override information given in the “simple form” position. To give a contrived example,
2.7.*versions and not
- environments track user-requested state: Building on our enhanced MatchSpec query language, conda environments now also track and differentiate (a) packages added to an environment because of an explicit user request from (b) packages brought into an environment to satisfy dependencies. For example, executing
conda install conda-forge::scikit-learn
will confine all future changes to the scikit-learn package in the environment to the conda-forge channel, until the spec is changed again. A subsequent command conda install scikit-learn=0.18 would drop the
conda-forgechannel restriction from the package. And in this case, scikit-learn is the only user-defined spec, so the solver chooses dependencies from all configured channels and all available versions.
- errors posted to core maintainers: In previous versions of conda, unexpected errors resulted in a request for users to consider posting the error as a new issue on conda’s github issue tracker. In conda 4.4, we’ve implemented a system for users to opt-in to sending that same error report via an HTTP POST request directly to the core maintainers.
When an unexpected error is encountered, users are prompted with the error report followed by a
[y/N]input. Users can elect to send the report, with ‘no’ being the default response. Users can also permanently opt-in or opt-out, thereby skipping the prompt altogether, using the boolean
- various UI improvements: To push through some of the big leaps with transactions in conda 4.3, we accepted some regressions on progress bars and other user interface features. All of those indicators of progress, and more, have been brought back and further improved.
- aggressive updates: Conda now supports an
aggressive_update_packagesconfiguration parameter that holds a sequence of MatchSpec strings, in addition to the
pinned_packagesconfiguration parameter. Currently, the default value contains the packages
openssl. When manipulating configuration with the
conda configcommand, use of the
--envflags will be especially helpful here. For example,
conda config --system --add aggressive_update_packages defaults::pyopenssl
would ensure that, system-wide, solves on all environments enforce using the latest version of
conda config --add pinned_packages python=2.7 --env
would lock all solves for the current active environment to python versions matching
- other configuration improvements: In addition to
conda config --describe, which shows detailed descriptions and default values for all available configuration parameters, we have a new
conda config --write-defaultcommand. This new command simply writes the contents of
conda config --describeto a condarc file, which is a great starter template. Without additional arguments, the command will write to the
.condarcfile in the user’s home directory. The command also works with the
--fileflags to write the contents to alternate locations. Conda exposes a tremendous amount of flexibility via configuration. For more information, The Conda Configuration Engine for Power Users blog post is a good resource.