Working with Anaconda

Tox uses virtualenv, typically creating a new environment for each build. Unfortunately, Tox does not support Anaconda. However, you can use tox on top of a Conda installation without issue. For example, you might have a build environment and run tox inside it:

conda create \
  --name build \
  --override-channels \
  --channel conda-forge \
  --force \
  --yes \
  pip install tox poetry

In addition, for several reasons, I strongly recommend using Poetry to manage dependencies instead of Anaconda. (Also, I recommend using Miniconda and conda-forge, as I recommended to a user who broke their conda base.)

If you need a dependency only available via Conda

Unfortunately, you may occasionally have dependencies that are available through Anaconda but not PyPi. One such offending package is rdkit, and there has been a lot of discussion about this issue. Aside from a handful of scientific packages, this is a rare situation. Likely, the best choice is to extract the dependency into a new project. Your dependency can be built with conda, while your main package can be built and tested in CI independently of it. Integration tests can then live outside of both projects. See chemserve for an example solution.

If you really need the dependency coupled directly to your main code, document the requirement in your readme and add it to your GitHub Actions workflows. [Ensureconda]( and tox-conda may be helpful.

Anaconda environment file

You can generate an environment yml file using: tyrannosaurus env. It will check for packages on Conda-Forge and move packages not found to the pip: section.

Anaconda recipes

This describes how to generate a Conda recipe and [upload it to Conda-Forge. Your desired version must already be published on PyPi, which happens shortly after you create a GitHub release.

Initial recipe generation

You will only need to do this once:

  1. Run tyrannosaurus recipe, which will run grayskull.

  2. Check over your new recipe in recipes/projectname/meta.yaml. The recipe-generation command isn’t perfect, so fix errors if there are any.

  3. Fork from staged-recipes. Check out that repo in a new branch named the same as your project.

  4. Copy your recipe from recipes/projectname/meta.yaml into that fork (same path), along with your license file.

  5. Make a pull request. Tests in Azure will be run, and a maintainer will merge your request.


On Windows, you may need to run conda install m2-patch first.

If everything goes well, your package will be on Conda-Forge soon after.

Keeping the package up-to-date

A new feedstock repo will also be created. For example, see Tyrannosaurus’s own feedstock. You should receive an email that adds you to Conda-Forge. Accept it to gain write access to this feedstock. The same goes for anyone else listed as a maintainer in the recipe under recipe-maintainers:. A little after each new release on PyPi, you will get a pull request on the feedstock that bumps the version. Let the Azure tests pass, check over the diff – especially making sure that any changes to the dependencies are reflected correctly – then merge. That’s it: the conda-forge package should be automatically updated.