conda-pack: turning a conda environment into one relocatable folder

One folder that carries its own interpreter

conda-pack is a command line tool for creating relocatable conda environments.

The use case is stated compactly: this is useful for deploying code in a consistent environment, potentially in locations where python or conda isn't already installed. That is the whole point. A conda environment normally has a hardcoded prefix, the path it was created at, and everything inside it assumes that prefix. Move it somewhere else and the shebangs point at an interpreter that is not there.

Packaging solves that by producing a copy of the environment with the paths made independent of where it was created, so the result can be unpacked at a different path and still work. That is what relocatable means here, and it is why the tool exists rather than a plain tar of the environment directory.

The result is a directory you can move, copy, ship in an archive or mount somewhere, and unpack with the interpreter inside it. There is no installation step on the target, no dependency resolution on the target, and no requirement that conda be present. For a team that wants a colleague to run the exact environment, or for a deployment onto hardware you do not control, that removes a category of problems.

The project is maintained under the conda organisation, the documentation lives at conda.github.io/conda-pack, and the licence is a New BSD licence with the file in the repository. The recent releases are 0.9.2 from 2026-06-16, 0.9.1 from 2026-01-22 and 0.9.0 on the same day in January, with the last push on 2026-10-20.

A small tool with a small dependency list

The packaging metadata says more about the project's shape than the readme does.

The runtime dependencies list contains exactly one entry, setuptools. For a tool that copies and rewrites a conda environment, that is a very small surface, and it is consistent with a design where the tool inspects the environment it is asked to pack rather than pulling in a large dependency resolution stack of its own.

The build backend is setuptools with setuptools_scm, and the version is dynamic, written to conda_pack/_version.py. So the version is derived from the git tags rather than typed into the source, which is the standard arrangement for a project that releases from a tag and does not want the version to drift between the tag and the artefact.

The console entry point is a single command, conda-pack, mapped to conda_pack.cli:main, so the whole user interface is one executable with a subcommand structure behind it.

The classifiers describe the supported range honestly. Python 3.9 through 3.13 are listed, and requires-python is 3.9 or newer, so the project is explicit about the oldest interpreter it claims to work with. The development status is given as 4, Beta, and the topic classifiers are the three that describe the tool's purpose: System :: Archiving :: Packaging, System :: Software Distribution, and Software Development :: Build Tools.

The authorship is also stable. Jim Crist is listed as both the author and the maintainer, which for a tool in the conda organisation is a useful thing to know, because a single-maintainer project is a different risk from a team-owned one.

Three ways to install it, and the one for contributors

The readme lists three install routes, and the choice between them is a signal about how the project is distributed.

The first is the defaults channel, with conda install defaults::conda-pack. The second is conda-forge, with conda install conda-forge::conda-pack. The third is the ctools development label, with conda install ctools/label/dev::conda-pack.

Having a defaults channel entry matters more than it might look. The defaults channel is the one conda itself ships with, so the tool is installable in a fresh conda installation without adding a third-party channel, which is a significant convenience for a tool whose whole job is to help people deploy Python software.

The conda-forge entry is the one most users of the wider conda ecosystem will actually use, and the ctools dev label is the one that tracks the development branch, which is the conventional arrangement for a project hosted on the conda organisation: stable builds in the published channels, and a rolling dev label for anyone who wants to test the tip.

The presence of a dev label rather than a single stable channel is worth noting for a different reason. It means the conda organisation runs a continuous build for this project, so a merge to the default branch produces a new package version without a human release step. That is the mechanism behind the release cadence visible in the tags, and it is also why the version is derived from git rather than maintained by hand.

Per platform scripts, and what they imply about moving an environment

One detail in the packaging configuration carries more information than it looks like it does.

The package data includes scripts/windows/* and scripts/posix/*. Those are per-platform helper scripts that ship inside the package and get used when an environment is packed.

The reason a packer needs platform-specific helpers is that making an environment relocatable is not a pure file copy. The prefix path is embedded in text files across the environment, and the way you find and rewrite it differs by platform. On POSIX systems the interpreter paths live in shebang lines at the head of scripts, and the fix is to rewrite those first lines. On Windows there are no shebangs, and the equivalent work happens in the launcher executables and the path configuration the runtime reads. A single tool that produced correct output on both platforms therefore needs two different mechanisms, which is exactly what the two script directories represent.

This also tells you something about the limits of the approach. The rewriting works on paths the tool knows about, and an environment with a package that hardcodes its own installation path in some other form is the kind of thing that can survive the move and break later. That is a general property of relocatable environments rather than a flaw in this one, but it is the reason to test the packed environment at its destination path rather than assuming it works because the pack step returned without error.

The build and test tooling around the package is conventional and well specified. Flake8 excludes __init__.py and sets a maximum line length of 100, isort uses the black profile at the same length, and black is configured for line length 100 targeting py39, so the three tools are aligned with each other. There is a coveragerc, a pre-commit configuration, and a Changelog.md alongside a news directory, which is the towncrier pattern for accumulating changes before they are cut into a release.

What the repository is for, and who uses it

The repository layout shows the shape of the project's day to day work.

The conda_pack directory is the package itself. The conda-recipe directory holds the recipe used to build the conda packages that get uploaded to the channels, which is how a source distribution becomes a channel entry. The docs directory is the documentation that is published to the site the readme points at. The testing directory holds the tests, and there is a separate sample directory, suggesting the tests exercise real environments rather than fixtures only.

There are also the process files. CONTRIBUTING.md, CODE_OF_CONDUCT.md and a pre-commit configuration sit alongside HOW_WE_USE_GITHUB.md, which is a short document about how the project uses GitHub. The presence of that file is a small signal: it means the maintainers have written down their expectations for issues and pull requests, which matters for a project with a single named maintainer.

The tool is aimed at whoever has a conda environment and needs to move it. In practice that is a team deploying an internal application to a server that does not have conda, a vendor shipping a Python application to a customer, a researcher handing over a reproducible environment with a paper or a dataset, and anyone who wants a single artefact instead of a lock file and a solver run on the target.

The one place the readme is thin is the detail of how the packing works, since that is delegated to the documentation site. The repository's own guidance is to see the documentation for more information, and that is where the command reference, the options and the caveats about what can and cannot be relocated will be.

Editorial conclusion

Adopt conda-pack if you deploy a Python application to a machine that does not have conda, or if you want to hand a colleague or a customer one folder that behaves exactly like the environment you tested in. Do not adopt it if you are already deploying with Docker images or with a compiled standalone binary, because it is a repackaging tool for conda environments and not a distribution format in its own right. Before you commit, pack the environment on the same platform you will deploy to, since the package ships separate script sets for Windows and for POSIX systems, and verify that the packed environment still resolves its own paths after you move it.

Frequently asked questions

Official sources

1. conda/conda-pack on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases