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

export PATH="/opt/conda/bin:$PATH"

in your ~/.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

. /opt/conda/etc/profile.d/conda.sh
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 ~/Anaconda3 or ~/miniconda2.

For system-wide conda installs, to make the conda command available to all users, rather than manipulating individual ~/.bashrc (or ~/.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 activate and conda deactivate are now the preferred commands for activating and deactivating environments. You’ll find they are much more snappy than the source activate and source deactivate commands from previous conda versions. The conda activate command 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_constrained keyword, which takes a list of package specs similar to the run keyword, is recognized under the requirements section of meta.yaml. For backward compatibility with versions of conda older than 4.4, a requirement may be listed in both the run and the run_constrained section. 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 repodata.json under a constrains keyword, parallel to the depends keyword 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 create, install, update, and remove operations. 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-forge channel. As before, the difference between python=3.5 and python==3.5 is 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.5 and <3.6. The exact spec will match only python packages with version 3.5, 3.5.0, 3.5.0.0, etc. The canonical string form for a MatchSpec is thus

    (channel::)name(version(build_string))

    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
    dependencies:
     - 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, python==3.5[version='>=2.7,<2.8'] will match 2.7.* versions and not 3.5.

  • 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-forge channel 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 report_errors configuration parameter.

  • 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_packages configuration parameter that holds a sequence of MatchSpec strings, in addition to the pinned_packages configuration parameter. Currently, the default value contains the packages ca-certificates, certifi, and openssl. When manipulating configuration with the conda config command, use of the --system and --env flags 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 pyopenssl from the defaults channel.

    conda config --add pinned_packages python=2.7 --env

    would lock all solves for the current active environment to python versions matching 2.7.*.

  • 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-default command. This new command simply writes the contents of conda config --describe to a condarc file, which is a great starter template. Without additional arguments, the command will write to the .condarc file in the user’s home directory. The command also works with the --system, --env, and --file flags 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.