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
With the release of conda 4.4, we recommend a change to how the
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
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
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
environment variable is modified, and replacing it with
In the above, it’s assumed that
is the location where you installed miniconda or Anaconda Distribution. It may also be something like
For system-wide conda installs, to make the
command available to all users, rather than manipulating individual
) files for each user, just execute once
This will make the
command itself available to all users, but conda’s base (root) environment will not be activated by default. Users will still need to run
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
will make sure that whenever conda is installed or changed in an environment, the source of the package is always being pulled from the
channel. This will be useful for people who use
, 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,
andconda activateare now the preferred commands for activating and deactivating environments. You’ll find they are much more snappy than theconda deactivateandsource activatecommands from previous conda versions. Thesource deactivatecommand 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.conda activate
- 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
keyword, which takes a list of package specs similar to therun_constrainedkeyword, is recognized under therunsection ofrequirements. For backward compatibility with versions of conda older than 4.4, a requirement may be listed in both themeta.yamland therunsection. 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 inrun_constrainedunder arepodata.jsonkeyword, parallel to theconstrainskeyword for a package’s hard dependencies.depends
- enhanced package query language: Conda has a built-in query language for searching for and matching packages, what we often refer to as
. The MatchSpec is what users input on the command line when they specify packages forMatchSpec,create,install, andupdateoperations. With this release, MatchSpec (rather than a regex) becomes the default input forremove. We have also substantially enhanced our MatchSpec query language. For example,conda searchconda 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 thechannel. As before, the difference betweenconda-forgeandpython=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 >python==3.5and <=3.5. The exact spec will match only python packages with version3.6,3.5,3.5.0, etc. The canonical string form for a MatchSpec is thus220.127.116.11(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 packagecytoolz 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_0build number: 0<br />size : 1.1 MBarch : x86_64platform : Platform.linuxlicense : BSD 3-Clausesubdir : linux-64url : https://conda.anaconda.org/conda-forge/linux-64/cytoolz-0.8.2-py35_0.tar.bz2md5 : e42a03f799131d5af4196ce31a1084a7dependencies:<br />- 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']
versions and not3.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 theconda-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 booleanreport_errors
- 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
configuration parameter that holds a sequence of MatchSpec strings, in addition to theaggressive_update_packagesconfiguration parameter. Currently, the default value contains the packagespinned_packages,ca-certificates, andcertifi. When manipulating configuration with theopensslcommand, use of theconda configand--systemflags will be especially helpful here. For example,--envconda config --system --add aggressive_update_packages defaults::pyopenssl
would ensure that, system-wide, solves on all environments enforce using the latest version ofpyopenssl
channel.conda config --add pinned_packages python=2.7 --env
would lock all solves for the current active environment to python versions matching2.7.*
- other configuration improvements: In addition to
, which shows detailed descriptions and default values for all available configuration parameters, we have a newconda config --describecommand. This new command simply writes the contents ofconda config --write-defaultto a condarc file, which is a great starter template. Without additional arguments, the command will write to theconda config --describefile in the user’s home directory. The command also works with the.condarc,--system, and--envflags 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.--file