Skip to content

Conversation

@dcamron
Copy link
Member

@dcamron dcamron commented Sep 15, 2025

This represents a maximal, fully-specified pixi config, encompassing all of our current CI environments. Took some inspiration from geovista.

Why?

  • Fast and consistent conda env resolution and installation across platforms. Uses uv for pip deps too
  • prefix maintains published actions for using pixi in CI
  • Cache shared across projects locally and usable in CI
  • pixi binary is portable. Can use pixi-pack to share complete envs even without pixi binary
  • Tasks can replace doc makefiles and create convenient commands for use in CI or local dev across all platforms, and will update environments before executing
  • Deps, tasks, scripts, env vars, on-activation, supported platforms, and more, are configurable per-feature/per-environment
  • Selfishly, I'm using it more elsewhere and appreciate the consistency 😅

All of this could lead to some performance and convenience in CI and local development. Similarly, this could shrink the barrier to setting up a local dev environment and contributing, and shrink our (already small) support load there.

Current limitations & tradeoffs

  • I've moved all features out of the default. This means local setup is fast and doesn't pull in any dep groups until you ask, but it does mean you have to specify environments to run tasks. This is done with -e <env> or using the CLI interactive selector. If you include these in the default feature then eg pixi r pytest will "just work".
  • Current maximal config can result in .pixi size on disk ballooning quickly. It doesn't install more than you ask for, but if you start to cross out of latest you're chomping away at disk space and bandwidth.
  • No separate and complete "conda" and "pypi" dependency sets. This is technically doable, but requires separate dependency definitions. This might be doable with some external processing our existing requirements files.
  • Originally specified "minimum" as only platform compatible with linux-64, as tested in CI, but pixi can not currently lock cross-platform when the host platform is excluded. Minimum osx-arm64 currently does not resolve, so thanks for the help rosetta (you will be missed.)
  • Pixi not supported by dependabot right now. Does come with diff-to-markdown tool that can be used in a workflow to similar effect. Ticket is open for official support.
  • Pixi envs require some plumbing to work cleanly with some IDEs, notably pycharm/jetbrains. Ticket is open for official support.

Todos

  • Plumb in to existing CI
  • Plumb workflows to bump manifest and update lockfile
  • Investigate pinning strategies
  • Would like to reduce dependency specs to keep track of. Including pyproject.toml > project.dependencies automatically in pixi features is possible, but hasn't quite gotten me to where I'd want to be. I'd like to play around with this more and update. Geovista works the other way: export to environment.yml, parse to requirements.txt, list as dynamic project metadata.

Play around with it and share thoughts. I'll poke around with CI in the future.

@dcamron dcamron added Area: Infrastructure Pertains to project infrastructure (e.g. CI, linting) Type: Enhancement Enhancement to existing functionality Area: DevTools Pertains to tools for developers labels Sep 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: DevTools Pertains to tools for developers Area: Infrastructure Pertains to project infrastructure (e.g. CI, linting) Type: Enhancement Enhancement to existing functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant