pixi add
#
About#
Adds dependencies to the workspace
Usage#
Arguments#
-
<SPEC>
- The dependency as names, conda MatchSpecs or PyPi requirements
May be provided more than once.
required:true
Options#
-
--pypi
- The specified dependencies are pypi dependencies. Conflicts with
host
andbuild
-
--platform (-p) <PLATFORM>
- The platform for which the dependency should be modified
May be provided more than once.
-
--feature (-f) <FEATURE>
- The feature for which the dependency should be modified
default:default
-
--editable
- Whether the pypi requirement should be editable
Config Options#
-
--tls-no-verify
- Do not verify the TLS certificate of the server
-
--auth-file <AUTH_FILE>
- Path to the file containing the authentication token
-
--pypi-keyring-provider <PYPI_KEYRING_PROVIDER>
- Specifies whether to use the keyring to look up credentials for PyPI
options:disabled
,subprocess
-
--concurrent-solves <CONCURRENT_SOLVES>
- Max concurrent solves, default is the number of CPUs
-
--concurrent-downloads <CONCURRENT_DOWNLOADS>
- Max concurrent network requests, default is
50
Git Options#
-
--git (-g) <GIT>
- The git url to use when adding a git dependency
-
--branch <BRANCH>
- The git branch
-
--tag <TAG>
- The git tag
-
--rev <REV>
- The git revision
-
--subdir (-s) <SUBDIR>
- The subdirectory of the git repository to use
Update Options#
-
--no-install
- Don't modify the environment, only modify the lock-file
-
--revalidate
- Run the complete environment validation. This will reinstall a broken environment
-
--no-lockfile-update
- Don't update lockfile, implies the no-install as well
-
--frozen
- Install the environment as defined in the lockfile, doesn't update lockfile if it isn't up-to-date with the manifest file
env:PIXI_FROZEN
-
--locked
- Check if lockfile is up-to-date before installing the environment, aborts when lockfile isn't up-to-date with the manifest file
env:PIXI_LOCKED
Global Options#
-
--manifest-path <MANIFEST_PATH>
- The path to
pixi.toml
,pyproject.toml
, or the workspace directory
Description#
Adds dependencies to the workspace
The dependencies should be defined as MatchSpec for conda package, or a PyPI
requirement for the --pypi
dependencies. If no specific version is
provided, the latest version compatible with your workspace will be chosen
automatically or a * will be used.
Example usage:
pixi add python=3.9
: This will select the latest minor version that complies with 3.9.*, i.e., python version 3.9.0, 3.9.1, 3.9.2, etc.pixi add python
: In absence of a specified version, the latest version will be chosen. For instance, this could resolve to python version 3.11.3.* at the time of writing.
Adding multiple dependencies at once is also supported:
pixi add python pytest
: This will add bothpython
andpytest
to the workspace's dependencies.
The --platform
and --build/--host
flags make the dependency target
specific.
pixi add python --platform linux-64 --platform osx-arm64
: Will add the latest version of python for linux-64 and osx-arm64 platforms.pixi add python --build
: Will add the latest version of python for as a build dependency.
Mixing --platform
and --build
/--host
flags is supported
The --pypi
option will add the package as a pypi dependency. This cannot
be mixed with the conda dependencies
pixi add --pypi boto3
pixi add --pypi "boto3==version"
If the workspace manifest is a pyproject.toml
, adding a pypi dependency will
add it to the native pyproject project.dependencies
array or to the native
dependency-groups
table if a feature is specified:
pixi add --pypi boto3
will addboto3
to theproject.dependencies
arraypixi add --pypi boto3 --feature aws
will addboto3
to thedependency-groups.aws
array
Note that if --platform
or --editable
are specified, the pypi dependency
will be added to the tool.pixi.pypi-dependencies
table instead as native
arrays have no support for platform-specific or editable dependencies.
These dependencies will then be read by pixi as if they had been added to
the pixi pypi-dependencies
tables of the default or of a named feature.
The versions will be automatically added with a pinning strategy based on semver or the pinning strategy set in the config. There is a list of packages that are not following the semver versioning scheme but will use the minor version by default: Python, Rust, Julia, GCC, GXX, GFortran, NodeJS, Deno, R, R-Base, Perl
Examples#
pixi add numpy
pixi add numpy pandas "pytorch>=1.8"
pixi add "numpy>=1.22,<1.24"
pixi add --manifest-path ~/myworkspace/pixi.toml numpy
pixi add --host "python>=3.9.0"
pixi add --build cmake
pixi add --platform osx-64 clang
pixi add --no-install numpy
pixi add --no-lockfile-update numpy
pixi add --feature featurex numpy
pixi add --git https://github.com/wolfv/pixi-build-examples boost-check
pixi add --git https://github.com/wolfv/pixi-build-examples --branch main --subdir boost-check boost-check
pixi add --git https://github.com/wolfv/pixi-build-examples --tag v0.1.0 boost-check
pixi add --git https://github.com/wolfv/pixi-build-examples --rev e50d4a1 boost-check
# Add a pypi dependency
pixi add --pypi requests[security]
pixi add --pypi Django==5.1rc1
pixi add --pypi "boltons>=24.0.0" --feature lint
pixi add --pypi "boltons @ https://files.pythonhosted.org/packages/46/35/e50d4a115f93e2a3fbf52438435bb2efcf14c11d4fcd6bdcd77a6fc399c9/boltons-24.0.0-py3-none-any.whl"
pixi add --pypi "exchangelib @ git+https://github.com/ecederstrand/exchangelib"
pixi add --pypi "project @ file:///absolute/path/to/project"
pixi add --pypi "project@file:///absolute/path/to/project" --editable
pixi add --git https://github.com/mahmoud/boltons.git boltons --pypi
pixi add --git https://github.com/mahmoud/boltons.git boltons --branch main --pypi
pixi add --git https://github.com/mahmoud/boltons.git boltons --rev e50d4a1 --pypi
pixi add --git https://github.com/mahmoud/boltons.git boltons --tag v0.1.0 --pypi
pixi add --git https://github.com/mahmoud/boltons.git boltons --tag v0.1.0 --pypi --subdir boltons
Tip
If you want to use a non default pinning strategy, you can set it using pixi's configuration.
The default issemver
which will pin the dependencies to the latest major version or minor for v0
versions.
Note
There is an exception to this rule when you add a package we defined as non semver
, then we'll use the minor
strategy.
These are the packages we defined as non semver
:
Python, Rust, Julia, GCC, GXX, GFortran, NodeJS, Deno, R, R-Base, Perl