Alternative to Conda Installers#

Anaconda Distribution, Miniconda, and Miniforge are the familiar ways many users get conda. cx is not a demand to move away from them. It is an alternative bootstrap path for users who want a native executable, a locked first install, and an opinionated base prefix.

What stays familiar#

After bootstrap, cx delegates ordinary commands to the installed conda executable:

cx create -n analysis python=3.12 numpy pandas
cx install -n analysis scipy matplotlib
cx list -n analysis
cx env list

The packages still come from conda channels. The default channel is conda-forge, and the installed prefix is a standard conda prefix on disk.

What changes#

The base prefix is managed more strictly than a typical Anaconda Distribution, Miniconda, or Miniforge base:

  • cx bootstraps into ~/.conda/express by default.

  • The base prefix is frozen after bootstrap, so day-to-day work should happen in named environments.

  • Activation can use cx shell ENV, powered by conda-spawn, without requiring conda init.

Try cx side by side#

You can try cx without changing an existing Anaconda Distribution, Miniconda, or Miniforge installation:

cx bootstrap
cx create -n cx-test python=3.12
cx shell cx-test
python --version
exit

cx manages its own prefix. Do not point it at an existing Anaconda Distribution, Miniconda, or Miniforge base prefix.

Recreate an existing environment#

If you have an environment.yml, pass the command through cx:

cx env create -f environment.yml
cx shell my-environment

If the file does not name the environment, choose one explicitly:

cx env create -n analysis -f environment.yml
cx shell analysis

When to keep using an installer distribution#

Keep using a traditional installer when that is the approved path for your organization, classroom, cluster image, or vendor workflow. cx is most useful when you want the conda CLI with a smaller bootstrap artifact, a locked first-run setup, a frozen base prefix, or an offline cxz binary.