A new flag, ‘–envs’, has been added to ‘conda search’. In this mode,
‘conda search’ will look for the package query in existing conda environments
on your system. If ran as UID 0 (i.e. root) on unix systems or as an
Administrator user on Windows, all known conda environments for all users
on the system will be searched. For example, ‘conda search –envs openssl’
will show the openssl version and environment location for all
conda-installed openssl packages.

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:

exportPATH="/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.shcondaactivatebase

In the above, it’s assumed that /opt/conda is the location where you installed miniconda or Anaconda. 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:

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.

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). 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:

condainstallconda-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:

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:

condainstallconda-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:

condaconfig--addaggressive_update_packagesdefaults::pyopenssl--system

would ensure that, system-wide, solves on all environments enforce using the latest version of pyopenssl from the defaults channel.

`condaconfig--addpinned_packagespython=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.

the conda ‘root’ environment is now generally referred to as the ‘base’ environment

Conda 4.4 now warns when available information about per-path sha256 sums and file sizes
do not match the recorded information. The warning is scheduled to be an error in conda 4.5.
Behavior is configurable via the safety_checks configuration parameter.

Further refine conda channels specification. To verify if the url of a channel
represents a valid conda channel, we check that noarch/repodata.json and/or
noarch/repodata.json.bz2 exist, even if empty. (#3739)

Unlink and Link Packages in a Single Transaction: In the past, conda hasn’t always been safe
and defensive with its disk-mutating actions. It has gleefully clobbered existing files, and
mid-operation failures leave environments completely broken. In some of the most severe examples,
conda can appear to “uninstall itself.” With this release, the unlinking and linking of packages
for an executed command is done in a single transaction. If a failure occurs for any reason
while conda is mutating files on disk, the environment will be returned its previous state.
While we’ve implemented some pre-transaction checks (verifying package integrity for example),
it’s impossible to anticipate every failure mechanism. In some circumstances, OS file
permissions cannot be fully known until an operation is attempted and fails. And conda itself
is not without bugs. Moving forward, unforeseeable failures won’t be catastrophic. (#3833, #4030)

Progressive Fetch and Extract Transactions: Like package unlinking and linking, the
download and extract phases of package handling have also been given transaction-like behavior.
The distinction is the rollback on error is limited to a single package. Rather than rolling back
the download and extract operation for all packages, the single-package rollback prevents the
need for having to re-download every package if an error is encountered. (#4021, #4030)

Generic- and Python-Type Noarch/Universal Packages: Along with conda-build 2.1.0, a
noarch/universal type for python packages is 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-packages directory to the correct location for the python version
in the environment,

conda maps the python-scripts directory to either $PREFIX/bin or $PREFIX/Scripts depending
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. (#3712)

Multi-User Package Caches: While the on-disk package cache structure has been preserved,
the core logic implementing package cache handling has had a complete overhaul. Writable and
read-only package caches are fully supported. (#4021)

Python API Module: An oft requested feature is the ability to use conda as a python library,
obviating the need to “shell out” to another python process. Conda 4.3 includes a
conda.cli.python_api module that facilitates this use case. While we maintain the user-facing
command-line interface, conda commands can be executed in-process. There is also a
conda.exports module to facilitate longer-term usage of conda as a library across conda
conda releases. However, conda’s python code is considered internal and private, subject
to change at any time across releases. At the moment, conda will not install itself into
environments other than its original install environment. (#4028)

Remove All Locks: Locking has never been fully effective in conda, and it often created a
false sense of security. In this release, multi-user package cache support has been
implemented for improved safety by hard-linking packages in read-only caches to the user’s
primary user package cache. Still, users are cautioned that undefined behavior can result when
conda is running in multiple process and operating on the same package caches and/or
environments. (#3862)

Conda now has the ability to refuse to clobber existing files that are not within the unlink
instructions of the transaction. This behavior is configurable via the path_conflict
configuration option, which has three possible values: clobber, warn, and prevent. In 4.3,
the default value will be clobber. That will give package maintainers time to correct current
incompatibilities within their package ecosystem. In 4.4, the default will switch to warn,
which means these operations continue to clobber, but the warning messages are displayed. In
4.5, the default value will switch to prevent. As we tighten up the path_conflict
constraint, a new command line flag –clobber will loosen it back up on an ad hoc basis.
Using –clobber overrides the setting for path_conflict to effectively be clobber for
that operation.

Conda signed packages have been removed in 4.3. Vulnerabilities existed. An illusion of security
is worse than not having the feature at all. We will be incorporating The Update Framework
into conda in a future feature release. (#4064)

New Configuration Engine: Configuration and “operating context” are the foundation of conda’s functionality. Conda now has the ability to pull configuration information from a multitude of on-disk locations, including .d directories and a .condarc file within a conda environment), along with full CONDA_ environment variable support. Helpful validation errors are given for improperly-specified configuration. Full documentation updates pending. (#2537, #3160, #3178)

New Exception Handling Engine: Previous releases followed a pattern of premature exiting (with hard calls to sys.exit()) when exceptional circumstances were encountered. This release replaces over 100 sys.exit calls with python exceptions. For conda developers, this will result in tests that are easier to write. For developers using conda, this is a first step on a long path toward conda being directly importable. For conda users, this will eventually result in more helpful and descriptive errors messages. (#2899, #2993, #3016, #3152, #3045)

Empty Environments: Conda can now create “empty” environments when no initial packages are specified, alleviating a common source of confusion. (#3072, #3174)

Conda in Private Env: Conda can now be configured to live within its own private environment. While it’s not yet default behavior, this represents a first step toward separating the root environment into a “conda private” environment and a “user default” environment. (#3068)

Regex Version Specification: Regular expressions are now valid version specifiers. For example, ^1\.[5-8]\.1$|2.2. (#2933)

Channel order now matters. The most significant conda change is that
when you add channels, channel order matters. If you have a list of channels
in a .condarc file, conda installs the package from the first channel where
it’s available, even if it’s available in a later channel with a higher
version number.

No version downgrades. Conda remove no longer performs version
downgrades on any remaining packages that might be suggested to resolve
dependency losses; the package will just be removed instead.

New YAML parser/emitter. PyYAML is replaced with ruamel.yaml,
which gives more robust control over yaml document use.
More on ruamel.yaml

Shebang lines over 127 characters are now truncated (Linux, macOS
only).Shebangs are
the first line of the many executable scripts that tell the operating
system how to execute the program. They start with #!. Most OSes
don’t support these lines over 127 characters, so conda now checks
the length and replaces the full interpreter path in long lines with
/usr/bin/env. When you’re working in a conda environment that
is deeply under many directories, or you otherwise have long paths
to your conda environment, make sure you activate that environment
now.

Changes to conda list command. When looking for packages that
aren’t installed with conda, conda list now examines the Python
site-packages directory rather than relying on pip.

Changes to conda remove command. The command condaremove--all
now removes a conda environment without fetching information from a remote
server on the packages in the environment.

Conda update can be turned off and on. When turned off, conda will
not update itself unless the user manually issues a conda update command.
Previously conda updated any time a user updated or installed a package
in the root environment. Use the option condaconfigsetauto_update_condafalse.

Improved support for BeeGFS. BeeGFS is a parallel cluster file
system for performance and designed for easy installation and
management. More on BeeGFS

Shortcuts are no longer installed by default on Windows. Shortcuts can
now be installed with the --shortcuts option. Example 1: Install a shortcut
to Spyder with condainstallspyder--shortcut. Note if you have Anaconda
(not Miniconda), you already have this shortcut and Spyder. Example 2:
Install the open source package named console_shortcut. When you click
the shortcut icon, a terminal window will open with the environment
containing the console_shortcut package already activated. condainstallconsole_shortcut--shortcuts

Skip binary replacement on Windows. Linux & macOS have binaries that
are coded with library locations, and this information must sometimes be
replaced for relocatability, but Windows does not generally embed prefixes
in binaries, and was already relocatable. We skip binary replacement on
Windows.

new version comparison algorithm, which consistently compares any version string, and better handles version strings using things like alpha, beta, rc, post, and dev. This should remove any inconsistent version comparison that would lead to conda installing an incorrect version.

use the trash in rm_rf, meaning more things will get the benefit of the trash system on Windows

print which file leads to the “unable to remove file” error on Windows

add support for the no_proxy environment variable, #1171

add a much faster hint generation for unsatisfiable packages, which is now always enabled (previously it would not run if there were more than ten specs). The new hint only gives one set of conflicting packages, rather than all sets, so multiple passes may be necessary to fix such issues

conda extensions that import conda should use conda.cli.conda_argparser.ArgumentParser instead of argparse.ArgumentParser to conform to the conda help guidelines (e.g., all help messages should be capitalized with periods, and the options should be preceded by “Options:” for the sake of help2man).

change the default for adding cache from the local package cache - known is now the default and the option to use index metadata from the local package cache is –unknown

add –alt-hint as a method to get an alternate form of a hint for unsatisfiable packages

add conda package –ls-files to list files in a package

add ability to pin specs in an environment. To pin a spec, add a file called pinned to the environment’s conda-meta directory with the specs to pin. Pinned specs are always kept installed, unless the –no-pin flag is used.

Try installing packages using the old way of just installing the maximum versions of things first. This provides a major speedup of solving the package specifications in the cases where this scheme works.

Don’t include python=3.3 in the specs automatically for the Python 3 version of conda. This allows you to do “conda create -n env package” for a package that only has a Python 2 version without specifying “python=2”. This change has no effect in Python 2.

Automatically put symlinks to conda, activate, and deactivate in each environment on Linux and macOS.

On Linux and macOS, activate and deactivate now remove the root environment from the PATH. This should prevent “bleed through” issues with commands not installed in the activated environment but that are installed in the root environment. If you have “setup.py develop” installed conda on Linux or macOS, you should run this command again, as the activate and deactivate scripts have changed.

Begin work to support Python 3.4.

Fix a bug in version comparison

Fix usage of sys.stdout and sys.stderr in environments like pythonw on Windows where they are nonstandard file descriptors.

add conda convert command to convert non-platform-dependent packages from one platform to another (experimental)

unify create, install, and update code. This adds many features to create and update that were previously only available to install. A backwards incompatible change is that conda create -f now means –force, not –file.

improve integration with pip
* conda list now shows pip installed packages
* conda install will try to install via “pip install” if no conda package is available (unless –no-pip is provided)
* conda build has a new –build-recipe option which will create a recipe (stored in <root>/conda-recipes) from pypi then build a conda package (and install it)
* pip list and pip install only happen if pip is installed

enhance the locking mechanism so that conda can call itself in the same process.