How to Get Ready for the Release of conda 4.4

 

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<br />$ conda update conda<br />$ 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<br />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<br />
    --------------------<br />
    file name   : cytoolz-0.8.2-py35_0.tar.bz2 <br />
    name        : cytoolz <br />
    version     : 0.8.2 <br />
    build string: py35_0

    build number: 0<br />
    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:<br />

     

    - python 3.5*

     

    - toolz &gt;=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='&gt;=2.7,&lt;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.


You May Also Like

Company Blog
Introducing Anaconda Enterprise 5
Anaconda Enterprise 5 is built for your entire organization and serves the needs of Data Scientists, IT Administrators, Business Analysts & Managers, Developers and Machine Le...
Read More
Data Science Blog
Who You Gonna Call? Halloween Tips & Treats to Protect You from Ghosts, Gremlins…and Software Vulnerabilities
Happy Halloween, readers. At Anaconda, we’re not too scared about things that go bump in the night. We’ve examined the data and concluded that it’s just the cleaning sta...
Read More
Data Science Blog
Choose Your Anaconda IDE Adventure: Jupyter, JupyterLab, or Apache Zeppelin
As humans we are faced with multiple choices every day. Every person is different: some people prefer Firefox while others like Chrome; some people prefer Python while others ...
Read More