Skip to content

Options

--conda

If you wish to specify a particular conda/mamba executable to use to perform the solve this can be provided as follows

conda-lock --conda some_path_to_conda

--mamba

If you want to make use of mamba in order to perform faster solves this can be enabledd with

conda-lock --mamba some_path_to_conda

If mamba is not installed, it will attempt to install it using ensureconda

--filename-template

By default, conda-lock store its output in conda-lock.yml in the current working directory. This file will also be used by default for render, install, and update operations. You can supply a different filename with e.g.

conda-lock --lockfile superspecial.conda-lock.yml

The extension .conda-lock.yml will be added if not present. Rendered environment files (env or explicit) will be named as as "conda-{platform}.lock".

If you want to override that call conda-lock as follows.

conda-lock -k explicit --filename-template "specific-{platform}.conda.lock"

The following fields are available for templating

field
platform the platform for lock file (conda subdir)
dev-dependencies true/false flag for --dev-dependencies
input-hash a sha256 hash of the lock file input specification
version the version of conda-lock used
timestamp the timestamp of the output file in ISO8601 basic format

--channel

You can override the channels that are used by conda-lock in case you need to override the ones specified in an [environment.yml][envyaml] or any of the other supported formats.

conda-lock --channel conda-forge

--platform

You may specify the platforms you wish to target by default directly in an [environment.yml][envyaml]

If you specify target platforms on the command line with --platform, these will override the values in the environment specification. If neither platforms (from source files) nor --platforms are provided, conda-lock will fall back to a default set of platforms.

--dev-dependencies/--no-dev-dependencies

By default conda-lock will include dev dependencies in the specification of the lock (if the files that the lock is being built from support them). This can be disabled easily

conda-lock --no-dev-dependencies --file ./recipe/meta.yaml

--extras or --categories

If your source files contains optional dependencies/extras these can be included in the output of a render by using the flag.

conda-lock --extra mysql --extra pgsql -f pyproject.toml

When generating lockfiles that make use of extras it is recommended to make use of --filename-template covered here.

By default conda-lock will attempt to solve for ALL extras/categories it discovers in sources. This allows you to render or install from lockfiles of extras without needing to re-lock.

However this does make the assumption that all extras are installed, and installable in conjunction with each other. If you want extras filtering to happen at the before solving use the flag --filter-categories or --filter-extras

conda-lock --extra incompatiblea --filter-categories -f pyproject.toml

This will use categories from --extras/--categories flag as a filter at the specification build time.

--check-input-hash

Under some situation you may want to run conda lock in some kind of automated way (eg as a precommit) and want to not need to regenerate the lockfiles if the underlying input specification for that particular lock as not changed.

conda-lock --check-input-hash --platform linux-64

When the input_hash of the input files, channels match those present in a given lockfile, that lockfile will not be regenerated.

--strip-auth, --auth and --auth-file

Warning

This flag is only used for basic auth.

By default conda-lock will leave basic auth credentials for private conda channels in the manner in which they were specified.

This means that if you should specified your channel as

Non-leaky credentials

environment.yml
channels:
    - http://$CHANNEL_USER:$CHANNEL_PASSWORD@host.com/channel

The environment variables CHANNEL_USER and CHANNEL_PASSWORD will be required at install time.

Leaky credentials

environment.yml
channels:
    - http://username:password123@host.com/channel

When used with explicit/env render targets you may wish to strip the basic auth from these files (regardless of if it is correctly or incorrectly specified).

conda-lock --strip-auth --file environment.yml

In order to conda-lock install a lock file with its basic auth credentials stripped, you will need to create an authentication file in .json format like this:

{
  "domain": "username:password"
}

If you have multiple channels that require different authentication within the same domain, you can additionally specify the channel like this:

{
  "domain.org/channel1": "username1:password1",
  "domain.org/channel2": "username2:password2"
}

You can provide the authentication either as a yaml/json string through --auth

conda-lock install --auth "{domain: 'username:$PASSWORD'}" conda-linux-64.lock

or as a filepath through --auth-file.

conda-lock install --auth-file auth.json conda-linux-64.lock

--virtual-package-spec

Conda makes use of virtual packages that are available at runtime to gate dependency on system features. Due to these not generally existing on your local execution platform conda-lock will inject them into the solution environment with a reasonable guess at what a default system configuration should be.

If you want to override which virtual packages are injected you can create a virtual package spec file

virtual-packages.yml
subdirs:
  linux-64:
    packages:
      __glibc: 2.17
      __cuda: 11.4
  win-64:
    packages:
      __cuda: 11.4

conda-lock will automatically use a virtual-packages.yml it finds in the the current working directory. Alternatively one can be specified explicitly via the flag.

conda lock --virtual-package-spec virtual-packages-cuda.yml --platform linux-64

Input hash stability

Virtual packages take part in the input hash so if you build an environment with a different set of virtual packages the input hash will change. Additionally the default set of virtual packages may be augmented in future versions of conda-lock. If you desire very stable input hashes we recommend creating a virtual-packages.yml file to lock down the virtual packages considered.

in conjunction with micromamba

Micromamba does not presently support some of the overrides to remove all discovered virtual packages, consequently the set of virtual packages available at solve time may be larger than those specified in your specification.