This post is adapted from a talk I gave at PyConDE & PyData 2026.

In it, I walk through the evolution of Python packaging, from distutils to pip, and later to conda, and how these tools emerged in response to different needs within the Python community.

The ideas in this post are based on my experience as a maintainer in the conda ecosystem and conversations I’ve had with users and contributors over time. A recurring theme in those discussions is the tendency to frame conda and pip as competing tools.

What I’ve found more useful is to view them instead as parts of different ecosystems, shaped by different constraints and priorities. That perspective also helps explain why mixing them can sometimes lead to unexpected behavior in practice.

This post is an attempt to share that perspective in a more structured form.

Conda and Pip: A Story of Two Ecosystems

If you've spent any time in the Python world, you've probably heard some version of this question:

"Should I use conda or pip?"

It usually comes up framed as a debate, sometimes even a heated one. People pick sides, compare features, and argue about which tool is "better."

But that framing misses something fundamental.

conda and pip were never meant to compete in the first place.

How We Got Here​

To understand why, it helps to take a step back and look at how Python packaging evolved.

In the early days, Python came with distutils, a module that let developers distribute and install software. If you wanted to install a package, you'd typically run something like python setup.py install. It worked, but just barely. There was no concept of uninstalling a package, no way to track dependencies, and improvements moved slowly because it was tied to Python's release cycle.

Frustration with these limitations led to the creation of setuptools in 2004. It extended distutils and introduced Easy Install, one of the first tools that could fetch packages from PyPI, the Python Package Index. For the first time, dependency management became part of the story, though still incomplete. Uninstalling packages, however, was still not really possible.

Then came pip in 2008, and things started to feel more modern. pip added proper uninstall support, better dependency handling, and, something people really appreciated at the time, clearer error messages. Around the same time, virtualenv introduced isolated environments, which solved a growing problem: everything had previously been installed into a single global directory. That meant different projects could easily break each other.

With virtual environments, each project got its own isolated space. Suddenly, it was possible to work on multiple projects without dependency conflicts. pip and virtualenv together became the standard workflow for a large part of the Python community.

The Gap pip Didn't Fill​

For many developers, this combination was more than enough. But there was an entire group of users for whom it wasn't.

Scientific computing introduced a different set of challenges. Libraries like NumPy and SciPy rely heavily on compiled C and Fortran code. Early versions of pip didn't handle these non-Python dependencies well, which meant users often had to install system-level libraries manually. That process could be fragile, confusing, and platform-dependent.

This is the context in which conda was created in 2012 by Anaconda, Inc. (at the time called Continuum Analytics).

conda took a different approach from the beginning. It was not limited to Python packages. Instead, it was designed as a general-purpose package and environment manager that could handle both Python and non-Python packages.

That meant it could install and manage compiled libraries like C and Fortran dependencies in the same way it handled Python packages.

And that difference in design philosophy is crucial.

conda wasn't trying to be a better version of pip. It was trying to solve a different problem.

Tools vs Ecosystems​

Once you see that, the "Conda vs pip" debate starts to feel a bit misplaced.

A more useful way to think about them is as ecosystems, not tools.

When you start thinking about conda and pip in terms of ecosystems, it becomes clear that they have different objectives and different design constraints. As a result, different tools naturally emerge within each ecosystem.

For example, newer tools like uv and Poetry belong to the pip ecosystem, while tools like mamba and pixi belong to the conda ecosystem.

Differences​

There are architectural and distributional differences between the two ecosystems.

• Package formats conda packages are distributed in .conda or .tar.bz2 formats. In the pip ecosystem, packages are distributed mainly as .whl (wheel files) or .tar.gz source distributions.

• Metadata structures Both ecosystems ship packages with "metadata" that helps package managers understand how to install and resolve dependencies, but they organize it differently. Each ecosystem uses its own directory structure and conventions for storing this information.

• Package locations conda packages are distributed through channels such as conda-forge and mains. pip packages, on the other hand, are distributed through package indices, most notably PyPI (Python Package Index).

• Package distribution Packages on PyPI are typically uploaded by the original authors. On the conda side, packages are distributed through channels. conda-forge performs downstream repackaging, and both authors and non-authors can upload packages there. There is however a "screening process" before packages can become available on conda-forge. The Anaconda main channel is restricted, and only Anaconda engineers can publish packages to it.

• Non-Python dependencies Packages on PyPI are typically uploaded by the original authors. On the conda side, packages are distributed through channels. conda-forge performs downstream repackaging, and both authors and non-authors can upload packages there. There is however a "screening process" before packages can become available on conda-forge. The Anaconda main channel is restricted, and only Anaconda engineers can publish packages to it.

When Worlds Collide​

Problems start to appear when these ecosystems are mixed without understanding how they interact.

At first glance, using pip inside a conda environment might seem harmless. In fact, it's quite common. But under the hood, the two tools don't share information with each other. conda keeps track of what it installs, and pip keeps track of what it installs, but neither fully understands the other.

This can lead to subtle and confusing issues. For example, conda may list a package as installed even after pip has removed it. Or conda might refuse to update a package because it doesn't recognize how it was installed. From the user's perspective, everything looks inconsistent, and debugging becomes frustrating.

What makes this especially tricky is that the errors don't always point clearly to the root cause. You might see a failure in your code and not realize it stems from a mismatch between package managers.

Why Mixing Still Happens​

Despite these pitfalls, people continue to mix conda and pip, and often for good reasons.

One of the biggest factors is sheer scale. PyPI hosts hundreds of thousands of packages, far more than what's available in conda channels. Inevitably, you'll encounter a package that exists only on PyPI.

Another reason is version availability. Even when a package exists in conda, the latest version might not be there yet. If you need that specific version, pip becomes the quickest option.

And then there's the reality of learning and experimentation. Developers often follow tutorials, copy commands from forums, and try different solutions until something works. In the process, it's easy to end up with a mix of tools, and a fragile environment.

Bridging the Gap​

Recognizing this reality, the community has been exploring ways to improve interoperability between the two ecosystems.

One of the latest efforts is conda-pypi, which brings PyPI packages into the standard conda workflow. Instead of reaching for pip, users can install compatible PyPI wheels directly through conda, with PyPI wheels handled as first-class artifacts alongside traditional conda packages.

This approach preserves the consistency and reliability that conda environments are known for, while giving users access to the broader pure Python ecosystem on PyPI.

It also adds guardrails to help maintain environment consistency. When enabled, it can block accidental pip install commands that could otherwise introduce conflicts or leave the environment in an unpredictable state, encouraging a more reliable and reproducible workflow.

conda-pypi represents an important shift in how the ecosystem thinks about interoperability: rather than treating PyPI and conda as competing worlds, it acknowledges that users often need both, and provides tooling designed to make that interaction smoother and safer.

A Shift in Perspective​

If there's one idea I hope you take away from this, it's this:

Stop thinking in terms of "which tool is better."

Start thinking in terms of ecosystems and context.

When you understand the problems each ecosystem was designed to solve, their differences start to make sense. You become more intentional about your choices, and less frustrated when things behave the way they do.

And perhaps most importantly, you begin to see the bigger picture.

Tools come and go. New ones will replace old ones. But ecosystems, the communities, ideas, and design principles behind them, tend to last much longer.

The workspace model itself comes from pixi by prefix.dev, where one TOML manifest declares a project's environments, features, platforms, and tasks. conda-workspaces is a conda plugin that brings that model to conda: it reads the same conda.toml, pixi.toml, or pyproject.toml manifest, materializes each declared environment as an ordinary conda prefix under .conda/envs/, and runs the declared tasks through the conda CLI. Nothing underneath is replaced: the same solver, package cache, channel authentication, and condarc that any other conda command uses keep doing the work.

“Isn’t that what pixi is for?”​

It is the first thing every reviewer asks.

pixi is its own complete stack: the workspace manifest, plus a Rust runtime (resolvo for solving and the rattler crates for conda primitives) distributed as a single binary. conda-workspaces reuses the manifest part and runs it through conda's stack instead. Both tools read the same conda.toml / pixi.toml / pyproject.toml and turn the declared environments into conda prefixes.

The difference is what sits underneath. conda-workspaces uses conda for everything below the manifest: conda's solver, conda's package cache, conda's transaction code, and whatever channel and authentication setup is already in condarc. Environments land under .conda/envs/ as ordinary conda prefixes. conda activate .conda/envs/test works. conda list works. Both tools can sit on the same pixi.toml and see the same dependencies, environments, and tasks. Each writes to its own subdirectory (.pixi/envs/ for pixi, .conda/envs/ for conda-workspaces), so the two tools never collide on disk.

What it looks like​

A conda.toml in the project root:

[workspace]
name = "my-project"
channels = ["conda-forge"]
platforms = ["linux-64", "osx-arm64", "win-64"]

[dependencies]
python = ">=3.10"
numpy = ">=1.24"

[feature.test.dependencies]
pytest = ">=8.0"
pytest-cov = ">=4.0"

[environments]
default = []
test = { features = ["test"] }

[tasks]
lint = "ruff check ."
test = { cmd = "pytest tests/ -v" }

[tasks.check]
depends-on = ["test", "lint"]

Then drive it from the conda CLI:

conda workspace install         # solve + install all envs + write conda.lock
conda workspace envs            # list the environments it built
conda task run check            # runs lint and test in dependency order
conda workspace shell -e test   # spawn a shell with the test env activated
conda workspace install --locked  # reproducible install from conda.lock

For projects that would rather skip writing a manifest by hand, conda workspace quickstart composes init, add, install, and shell into a single command. From an empty directory to an installed environment with an activated shell, in one step:

conda workspace quickstart python=3.14 numpy

--no-shell makes it CI-friendly, and --json returns a scriptable summary. See Your first workspace for the full walkthrough.

Why this exists​

The conda ecosystem has tried to solve this before.

anaconda-project was the first tool to attach project-scoped conda environments to a manifest, with command runners, downloads, and platform variants baked in. conda-project is its community successor, layering conda-lock on top for reproducibility. conda-devenv takes a different angle: Jinja2 over environment.yml for composition and inheritance. Each of these still has a healthy user base and solves the problem its constituency cares about. What none of them share is a manifest format with each other, or with anything outside the conda ecosystem.

pixi reframed what a TOML workspace manifest could look like (composable features, named environments, platform targeting, a built-in task runner), and that schema is what conda-workspaces uses. The manifest itself is, by design, identical between the two tools.

What conda-workspaces adds is a way to drive that same manifest from inside a conda installation. Solving uses conda or libmamba (or conda-rattler-solver when installed). Installation uses conda's transaction code. PyPI dependencies, when present, are handled by conda-pypi. Lockfile reading and writing route through conda-lockfiles. A workspace ends up looking, on disk, exactly like a directory full of conda environments.

That makes the two tools comfortably complementary. Teams that prefer pixi's batteries-included Rust experience keep using pixi. Teams that already live in the conda ecosystem (with their own channels, mirrors, authentication, and condarc) get the same workspace ergonomics without swapping out the rest of the stack. The same pixi.toml can live in a shared repo and serve both groups.

What it does​

One-command bootstrap​

conda workspace quickstart (shown above) takes a project from "no manifest" to "installed environment" in one step: it picks a manifest format, drops a sensible starting conda.toml (or pixi.toml, or [tool.conda.workspace] in pyproject.toml), solves, installs, and writes conda.lock. --copy <path> clones an existing workspace's manifest instead of running init, which is the fastest way to spin up a sister project from a known-good template.

Day-to-day edits go through conda workspace add and conda workspace remove, which by default install into the affected environments and refresh conda.lock in one step. --no-install and --no-lockfile-update opt back into manifest-only changes, and --dry-run solves without touching disk. The full flow is documented under Add and remove dependencies.

Multi-environment workspaces with composable features​

A feature is a reusable group of dependencies, channels, activation scripts, or environment variables. Environments compose features:

[feature.test.dependencies]
pytest = ">=8.0"
pytest-cov = ">=4.0"

[feature.docs.dependencies]
sphinx = ">=7.0"
myst-parser = ">=3.0"

[environments]
default = []
test = { features = ["test"] }
docs = { features = ["docs"] }
ci   = { features = ["test", "docs"] }

Each named environment is solved independently and installed under .conda/envs/<name>/. Cloning a repo is then all it takes to recreate every environment a project needs. See Environments for the full model.

PyPI dependencies in the same solve​

PyPI packages live in their own table and resolve in the same solver call as conda packages, so a workspace can mix the two without a separate pip install step:

[dependencies]
python = ">=3.10"
numpy = ">=1.24"

[pypi-dependencies]
my-local-pkg = { path = ".", editable = true }
some-pypi-only = ">=1.0"

[feature.test.pypi-dependencies]
pytest-benchmark = ">=4.0"

This path requires conda-pypi (which maps PyPI names to their conda equivalents and handles wheel extraction) and conda-rattler-solver as the solver backend. Both are still under active development, so PyPI integration is the most experimental part of conda-workspaces today. The common cases work (declared specs, named PyPI packages, plus editable / git / URL specs handed off to conda-pypi's build system after the main solve), and rough edges are being filed down upstream. If conda-pypi is not installed, PyPI dependencies are skipped with a warning, so a workspace that does not declare any works on a stock conda. Full reference in PyPI dependencies.

Multi-platform conda.lock​

conda workspace lock writes a single conda.lock that covers every platform every environment declares, not just the host. One file, one commit, one source of truth for cross-platform projects.

conda workspace lock
conda workspace lock --platform linux-64
conda workspace lock --platform linux-64 --platform osx-arm64
conda workspace lock --skip-unsolvable

Each platform's solve runs with conda pointed at the target platform rather than the host. That single switch picks the right channel repodata to fetch and makes conda's virtual package plugins (__linux, __osx, __win) report the target platform too, so a linux-64 lock generated on macOS sees the same world a linux-64 machine would. Tighter constraints come from CONDA_OVERRIDE_* or the [system-requirements] table when cross-compiling. Unknown platform names fail fast before any solver runs, so typos like lixux-64 get caught at parse time instead of after a 90-second metadata download.

conda workspace info exposes a Known Platforms row (and matching known_platforms JSON key) that surfaces the full set of platforms reachable through any feature, not just the workspace-level list. Full reference in Platform targeting.

CI-split locking with --merge​

Solving every platform from a single CI job becomes the bottleneck as a workspace grows. The lock command is matrix-friendly: each runner emits one fragment with --output, and a coordinator job stitches them back together with --merge, with no solver runs.

# In each matrix job
conda workspace lock \
    --platform linux-64 --output conda.lock.linux-64
conda workspace lock \
    --platform osx-arm64 --output conda.lock.osx-arm64
conda workspace lock \
    --platform win-64 --output conda.lock.win-64

# On the coordinator: pure file-level merge, no solving
conda workspace lock --merge "conda.lock.*"

--merge validates schema version and per-environment channel agreement, rejects overlapping (environment, platform) pairs, and produces output that is byte-identical to a single-job conda workspace lock over the same inputs. That last part is the one that matters: the merged lockfile is indistinguishable from one produced sequentially, so caching, hashing, and "lockfile changed?" diffs all behave normally. The flag matrix is documented under CI-split locking, and the CI pipeline tutorial wires the same flow into GitHub Actions end-to-end.

Cross-format conversion​

conda workspace export plugs into conda's conda_environment_exporters plugin hook. Every format reachable through conda export, plus anything a third-party plugin like conda-lockfiles registers, is reachable through conda workspace export and vice versa. conda-workspaces registers three of those exporters itself: conda-toml, pixi-toml, and pyproject-toml.

conda workspace export --file environment.yml
conda workspace export --format conda-toml --file conda.toml
conda workspace export --format pyproject-toml --file pyproject.toml
conda workspace export --from-lockfile --file env.conda-lock.yml
conda workspace export --from-prefix --no-builds --from-history

When the target file already exists, the pyproject-toml exporter splices the [tool.conda] subtree into the document and leaves the existing [project], [build-system], [tool.ruff], [tool.pixi], and friends untouched. Any stale [tool.conda] is replaced. Everything else survives. Full matrix in Export.

The reverse direction is conda workspace import. It detects the source format and writes a conda.toml next to it:

conda workspace import environment.yml
conda workspace import anaconda-project.yml
conda workspace import conda-project.yml
conda workspace import pixi.toml --dry-run
conda workspace import pyproject.toml --output conda.toml

The per-tool walkthroughs in the docs cover how each source format maps onto the workspace schema, including command and feature mappings, what carries over, and what does not: Coming from conda, Coming from conda-project, Coming from anaconda-project, and Coming from pixi.

Built-in task runner​

conda task ships in the same plugin. The design is borrowed from pixi: task dependencies with topological ordering, per-platform overrides, input/output caching, Jinja2 templates with a conda.* context, and named arguments with defaults.

[tasks]
lint  = "ruff check ."
build = { cmd = "python -m build", inputs = ["src/**/*.py"], outputs = ["dist/*.whl"] }
test  = { cmd = "pytest {{ test_path }} -v", depends-on = ["build"] }

[target.win-64.tasks]
clean = "rd /s /q build"

[tasks.check]
depends-on = ["test", "lint"]

Tasks defined in a workspace manifest run in the workspace's default environment, and -e <env> targets a different one. Tasks in a manifest with no workspace section run in whatever conda environment is active, which is useful for adopting conda task in a project that is not ready for a full workspace yet. Each capability has a dedicated section in the docs:

• Task dependencies
• Task arguments and template variables
• Task caching
• Platform-specific tasks

Install and try it​

conda-workspaces is a conda plugin, so a conda installation has to exist first. Installing into a conda base environment registers the conda workspace and conda task plugin subcommands. The standalone cw and ct shortcut commands are always installed and work without going through conda <subcommand> at all.

conda install --name base --channel conda-forge conda-workspaces

mamba install --name base -c conda-forge conda-workspaces
# or:
micromamba install --name base -c conda-forge conda-workspaces

pixi global install conda-workspaces

Then, in any directory:

conda workspace quickstart python numpy

That is it.

What it doesn't do​

A few things to set expectations.

It is not a replacement for pixi. If a self-contained, batteries-included project tool with its own solver, runtime, and cache is the right fit, pixi is the better answer. conda-workspaces is for teams that already live in the conda ecosystem and want pixi-style project workflows without moving everything else.

It does not change how conda is configured. Channels, authentication, mirrors, proxy settings, and .condarc continue to behave exactly the way they do for any other conda command. There is nothing new to teach existing tooling about.

It does not invent a new lockfile schema. conda.lock is intentionally compatible with the rattler-lock family so that lockfiles can be inspected, shared, and (eventually) standardized through the CEP process.

It does not require any of this all at once. A conda.toml with just a [tasks] table is a valid file: tasks run in whatever conda environment is currently active, and workspace features can be added later. Most projects start there.

Get involved​

conda-workspaces is a conda-incubator project. Contributions, bug reports, and feature requests are welcome:

• Documentation
• GitHub repository
• Issue tracker
• Migration guides for users coming from conda, conda-project, anaconda-project, or pixi

Acknowledgements​

The workspace and task design in conda-workspaces is directly inspired by the work of the prefix.dev team on pixi. Composable features, named environments, platform targeting, task dependencies, caching, and template variables all come from their playbook. Many thanks for it, and for keeping the manifest format open enough that two tools can share it.

Thanks also to the anaconda-project and conda-project teams for laying the groundwork on project-scoped conda long before this plugin existed, and to the conda-lock maintainers for years of work on cross-platform conda lockfiles (the idea conda.lock builds on, even though the on-disk format goes through rattler-lock). Finally, thanks to everyone who has filed issues, tested early releases, and pushed the design forward in the open.

Further reading​

• conda-workspaces documentation
• conda-workspaces motivation (the design rationale, in long form)
• conda-workspaces CLI reference
• conda-workspaces on GitHub
• Building a Better conda CLI: A Vision
• pixi workspace documentation
• conda plugin documentation

After extensive discussion with stakeholders across the community, I've laid out my vision for where conda could go. This included a maintainer offsite in Málaga, Spain, in December. I also looked at incubated and third-party projects that extend conda through its plugin system. Since that offsite, other maintainers have turned several of those ideas into experiments such as conda-ng to help show what is possible. I invite the broader community to help build it.

My name is Dan Yeaw, and I'm a Sr. Engineering Manager at Anaconda where I have been leading OSS projects for the last year. Since August, I've had the opportunity to lead the conda CLI OSS team, and I'm also on the conda-maintainers team. I've also started to get involved in conda-forge to get the full GTK GUI toolkit supported by adding feedstocks for libraries like libadwaita and gtksourceview.

Last month, I gave a talk at Michigan Python called "Designing Delightful CLIs with Python." The premise was that some CLI tools put a smile on your face, and some make you want to close the terminal and go for a walk. I asked the audience what CLI tool they actually enjoy using, and the answers were things like: Claude Code, uv, ripgrep, gh, bat. These tools are a new generation that feels alive, gives you feedback, and gets out of your way.

Then someone asked me: "What about conda?"

conda is one of the most powerful package managers in existence. It handles multi-language dependencies, manages complex environments, and serves everyone from data scientists running notebooks to engineers building production systems. But power and delight aren't always the same thing, and we have real work to do.

A Brief History​

Before we dive into the future, let's first spend a minute reflecting on the past. By the end of 2012, the Anaconda Distribution had about 100 packages and conda ran on Python 2.7. The CLI was a set of modules that used optparse, the precursor to argparse, and the progress bar library was vendored. Even so, the look and feel are not all that different from modern conda. Below, conda 1.4 shows its help output and creates an environment.

Fast-forward five years to 2017: conda 4.4 shipped with both Python 3.6 and 2.7 installers and included a major cleanup of the CLI. One large change was new conda activate and conda deactivate commands, which replaced source activate / source deactivate (on Linux/macOS) and activate / deactivate (on Windows). It also added a new spinner and used the tqdm library for progress bars. Those pieces are still in conda today.

conda 22.11.0, released in November 2022, added a pluggy-based hook system so conda could be extended with plugins.

2023 was also a big year: 23.10.0 switched the default solver from the classic pycosat implementation to libmamba via a solver plugin, which dramatically improved how long solves took.

In 2024, conda gained a reporter backend plugin, and Travis Hathaway put together a demo of what a more modern CLI could look like with the conda-rich incubator project.

In January 2025, Jaime Rodríguez-Guerra started conda-spawn, in the spirit of poetry shell and pixi shell: spawn a subshell with the environment already active instead of activating in place, so you can skip conda init hooks on every login. That keeps ordinary shell startup light and defers loading conda until you are ready to use it.

Finally, in December 2025, conda shipped sharded repodata in beta, a fundamental step forward for conda by cutting how much metadata you download and process.

A couple of takeaways from this: conda's CLI has kept a fairly consistent look and feel over the years, and the maintainers have been improving the experience incrementally. I'm grateful for that history and for the maintainers and community members who sustained it.

Fast, Trusted, and Delightful​

In my talk, I presented that great CLIs nail three things:

1. Fast
2. Trusted
3. Delightful

For fast, we aren’t just talking about benchmarks-fast, but perceived fast, where the tool communicates what it's doing so silence never turns into doubt. For trusted, the tool is transparent about its actions, careful about dangerous operations, and honest when things go wrong. Finally, for delightful we have sensible defaults, helpful suggestions, clean output, and just enough personality to remind you that a human thought about your experience.

That's the lens I would like to apply to my vision, so let’s dive into the details as part of this post.

Blazingly Fast​

Package management shouldn't be a coffee break. When I demoed conda next to pixi at Michigan Python, the contrast was stark, not because conda was dramatically slower, but because pixi communicated. Color, emoji, a real-time progress bar. The same underlying work, a completely different feeling. Speed is about perception as much as raw performance. Nielsen's research on response times shows that feedback within 100 ms feels instant and anything over a second creates uncertainty. In other words, silence is the enemy of responsiveness. conda has already landed substantial speedups, and we should keep building on that foundation. What I lay out below is mostly the next layer: how installs feel in the terminal and which primitives we lean into (progress and repodata, shell startup, and Rattler).

Our approach to speed has several dimensions:

• Progress over spinners – Replacing spinners with progress bars that show operation steps, package counts, and timing gives users confidence that work is happening and finishing. We can show meaningful progress during the fetching, downloading, and installing phases.
• Sharded repodata – As I mentioned above, sharded repodata is a game changer for performance, and the next step is that we need to enable this by default and ensure it is available on a wider set of channels.
• Shell startup – There should be no shell startup penalty for using conda, and my vision is that a conda-spawn approach to spawn a new subshell will become the default conda activate and conda deactivate behavior.
• Rattler integration – We would like to use Rattler more, a high-performance Rust implementation of core conda primitives. The performance floor rises significantly when the resolver and file I/O are written in Rust.

Our goal isn't to win a benchmark, but to make conda feel fast and responsive. Jaime Rodríguez-Guerra created a demo called conda-ng that demonstrates what a blazingly fast rattler-based conda might look like:

The conda-ng demo is deliberately Rattler-forward, but the conda you install today is not waiting on Rust to get faster. Sharded repodata and steady improvements to solving and repodata handling already changed what day-to-day installs feel like. Where we integrate Rattler further, it extends that groundwork.

Trusted​

Trust is the foundation everything else rests on. Unlike a GUI where you can normally click undo if something goes wrong, a CLI has real consequences. For example, if conda installs the wrong package, you could easily end up with a broken environment. Users need to trust that conda is telling them what's happening, that dangerous operations are clearly marked, and that routine operations don't require confirmation prompts. Here is what I envision to create more trust:

• Streaming output provides transparency – When conda shows you what it's resolving and downloading in real-time, you can spot problems early. It is also important for conda to provide a summary at the end of an operation to help increase confidence.
• Error messages are a conversation – conda should be a helpful colleague, and its error messages should state the cause clearly, show exactly what went wrong, and provide an actionable path to fix it. For example, Python 3.14 has improved error guidance which doesn't just report a syntax error, it tells you how to fix it.
• Match friction to a consequence – We should have a spectrum of interaction so that routine operations need no confirmation. Moderately risky operations get a preview and a brief pause. Genuinely dangerous operations like deleting an environment or wiping a package cache require a confirmation. Currently, conda asks for confirmation for most operations. This causes alert fatigue where users learn to dismiss prompts without reading them. Then, when an operation is genuinely dangerous, the confirmation prompts offer no real protection.

Delightful​

Delight is the part people tend to skip because it feels like polish on top of substance. However, I think this is the substance. A tool that delights users gets recommended to colleagues, it gets contributors, and it gets maintained and loved and improved. A few areas that I envision we focus on:

• Sensible defaults – A great CLI works out of the box. Beginners should succeed immediately without reading a configuration guide. Power users can opt into more control, but beginners shouldn't have to opt out of complexity. We also should think carefully before adding extra configurations, since each one added becomes an extra complexity for users to understand and an extra maintenance burden for the maintainers.
• Helpful suggestions – Type a mistyped command and conda should say "did you mean X?" This is the difference between a user feeling frustrated and feeling supported.
• Color and emoji with intention – Every visual element should do work. Green means success. Red means error. A progress emoji communicates stage without a wall of text.
• Accessibility – Delight has to be for all users. As we add intentional color and emoji, we also need to support the NO_COLOR environment variable to disable all color output, use colorblind-safe palettes that don't rely on red/green alone, and provide --no-progress for animation-sensitive users and automation environments. The GitHub CLI with its a11y subcommand does a great job with this, and we should have something similar.
• Progressive disclosure – Clean, minimal output by default and full debug detail with --verbose only when you need it. Right now conda displays too much information, which can be overwhelming and cause users to just ignore it. This matters for human users and for automation. Agents and scripts need reliable fields without fragile parsing of prose, and structured modes like --json help with that. Long JSON dumps also cost context tokens, so compact defaults and optional structured output both matter. The fact that we already have a JSON output mode is a strength of conda.

Excellence Beyond the CLI​

Fast, Trusted, and Delightful apply to more than the core CLI experience. A few other areas where this vision extends:

• Native PyPI support – If you look closely at the animation above, conda 1.4 shipped with a conda pip command. This shows that the Python ecosystem and PyPI are inextricably linked to conda from the very beginning. It is also a problem we have been trying to solve ever since. The conda-pypi plugin already supports natively installing wheels without shelling out to pip. My vision goes further: a conda channel that indexes all versions of all pure-Python wheels from PyPI directly in repodata, so they are always available without leaving the conda ecosystem.
• Declarative environments – Modern development workflows need modern configuration. We have recently been working on improving cross-platform lockfile support, and we need to continue to build on that. Poetry, uv, and pixi have shown that software engineers really value having the ability to run tasks and manage their dependencies through projects or workspaces. I envision that we support these workflows with an ecosystem-standardized conda.toml configuration file to help make your projects easier to manage and more reproducible, in the same direction conda-workspaces is already exploring.
• CI/CD and development environments – conda should excel where developers actually use it most in places like GitHub Actions, CI pipelines, and development containers. A lightweight single-binary conda bootstrapper that makes installation a one-line command would severely simplify this experience. It should also be easy to convert an environment into a container with dependencies already resolved and installed, not reconstructed during the container’s startup.
• Cross-platform excellence – Windows is home to the majority of conda users, and it deserves a first-class experience: the fastest installers, the most polished interface, the smoothest integration with Windows development workflows. As we perfect that experience, we bring those same improvements to macOS and Linux.
• A comprehensive API for frontend integration – The CLI is one way to interact with conda, but it shouldn’t be the only one. IDE integrations, Jupyter extensions, web interfaces, GUI tools, and even AI agents all deserve access to conda’s power without reimplementing it. A well-documented API built on conda and rattler makes that ecosystem possible.

Here is an example based on Jannis Leidel's proof-of-concept conda-express of what a future Miniconda installer could look like as a lightweight, single-binary:

Innovation Across the Ecosystem​

This vision is already starting to take shape through community-driven projects that extend conda through its plugin system.

conda-lockfiles is launching in the next few weeks in beta. It adds support for multiplatform lockfile formats, including conda-lock and pixi.lock, making cross-platform environment reproducibility a first-class conda feature.

conda-self is also launching in beta soon. It adds a conda self command that lets you safely manage your base environment, including protecting it from accidental modifications.

The following three projects are proof-of-concepts from Jannis Leidel that explore what future conda workflows could look like. Together with conda-lockfiles and conda-self, they paint a picture of covering all kinds of gaps in conda today:

conda-global enables installing CLI tools into isolated environments and placing them on your PATH, similar to pipx install, uv tool, or pixi global.

conda-express is the lightweight, single-binary bootstrapper shown above. My vision is that it becomes the future Miniconda and Miniforge installer itself, a small static binary that gets you a fully functional conda installation in seconds.

conda-workspaces brings a pixi-like project-based workflow to conda with project-scoped environments, composable features, a task runner with dependency ordering, and reproducible conda.lock files, all defined in a conda.toml (with pixi.toml and pyproject.toml manifests also supported). My vision is that workspaces become the future of environment management in conda. It builds on conda itself for solving and installation, and uses conda-pypi to resolve PyPI dependencies alongside conda packages. Cloning a repo should be all it takes to start working in a reproducible project.

These projects prove the ideas are sound, and many of them can and should keep evolving. Several are incubating in conda-incubator today. When a piece is ready, conda can take it on as a dependency and ship it as the default behavior without necessarily merging the whole implementation into the main conda codebase. My vision is that we keep investing in both the plugin ecosystem and core conda.

How To Get There​

This vision laid out above will not come to fruition without community involvement. I would like to see us organize more working groups around specific improvement areas, continue to strive to run our development in the open, and continue to guide changes through the Conda Enhancement Proposal (CEP) process. We have seen some huge strides in this area, especially with the recent foundational CEP approvals, however, we need to keep improving and strengthening our community. The Conda Community Calls so far this year have been really great discussions, and we’ll continue to chat on Zulip with the broader community so everyone can provide input.

An Invitation​

Whether you're a data scientist who knows where the pain points are, a contributor who wants to help solve them, or a maintainer helping to keep the lights on, we need your input and participation! The conda ecosystem has assets other package managers don't: contributors with deep expertise across an enormous range of use cases, multi-language package support, enterprise-scale real-world feedback, and a strong academic presence. We're building on a solid foundation.

The goal is a package manager that will be around for many years to come, and is trusted by researchers, loved by engineers, and recommended to anyone who's ever fought a dependency. Come help us build it.

Changes in conda 26.3.0/26.3.1​

To update conda to the latest version, run:

conda install --name base conda=26.3.1

Notable Changes:

• conda create --file and conda install --file accept environment.yaml as well as requirements.txt and explicit exports; with --name / --prefix omitted, the name or prefix is inferred from the file. -f is a recognized alias for --file (and is no longer an alias for --force).
• Richer solver metadata: PackageRecord.requested_specs and unmerged match specs through the solver and pre-solve plugins.
• Environment plugins support aliases, wildcard default_filenames, and new description / environment_format metadata.
• Faster conda run (inline activators), optimized S3 downloads, and improved Windows activation for paths containing ^.
• Clearer errors with PackagesNotFoundInChannelsError vs PackagesNotFoundInPrefixError; conda list --size shows non-zero sizes for metapackages; conda search --envs errors if the package is not found anywhere.
• Trust / signature verification moved out of core: the conda.trust module and built-in signature post-solve plugin are removed; use the conda-content-trust plugin when you need verification with extra_safety_checks.
• 26.3.1: plugin metadata records where each plugin was registered; diagnostics and conda info can surface that. Conda no longer discovers subcommands by scanning conda-* executables on PATH when building the CLI (prefer the plugin system).

Many long-deprecated APIs and legacy behaviors were removed in 26.3.0; see the release notes before upgrading automation that imports conda internals.

Full changelogs: 26.3.0, 26.3.1

Changes in conda-build 26.3.0​

conda install --name base conda-build=26.3.0

Notable changes:

• Build v1 recipes using the rattler-build CLI.
• Tar extraction sets an explicit filter for Python 3.14 compatibility.
• Dropped unused pytz dependency; recipe requires conda >=25.11.0 and conda-libmamba-solver >=25.11.0.

Full changelog: 26.3.0

Changes in conda-libmamba-solver 26.3.0​

conda install --name base conda-libmamba-solver=26.3.0

Notable changes:

• CEP 16 sharded repodata is marked ready for wider use (building on 25.11’s preliminary support).
• Offline mode can use cached shards (with sensible fallbacks); improved shard fetch fallbacks, channel ordering, sqlite cache recovery, and S3 URL joining; .tar.bz2 duplicates are dropped when .conda exists and use_only_tar_bz2 is off.

Full changelog: 26.3.0

Changes in conda-content-trust 0.3.0/0.3.1​

conda install conda-content-trust=0.3.1

Notable changes:

• CondaPostSolve hook for signature verification (migrated from conda’s former conda.trust implementation), aligned with conda 26.3’s plugin-based trust story.
• Supports Python 3.13 and 3.14; drops 3.8 and 3.9.

Full changelogs: 0.3.0, 0.3.1

Changes in conda-rattler-solver 0.0.6​

conda install conda-rattler-solver=0.0.6

Notable changes:

• Bumps py-rattler to 0.23.

Full changelog: 0.0.6

Changes in conda-standalone 26.1.1​

Notable changes:

• Updated embedded conda, libmambapy 2.5.0, and Python 3.13.12.
• Data files only for the native platform; PATH ordering fixed for classic (--classic) init; constructor extract legacy argument handling fixed.

Full changelog: 26.1.1

Changes in constructor 3.15.0 / 3.15.1​

conda install constructor=3.15.1

Notable changes (3.15.0):

• Support for installing protected (frozen) environments (CEP 22).
• INSTALLER_PATH (and INSTALLER_PLUGINSDIR for EXE) exposed to pre/post install scripts.
• Architecture checks on macOS .sh and .pkg installers; EXE pre-install script respects the UI checkbox; Mach-O signing under _internal for notarization.

3.15.1: EXE uninstaller fix for INSTDIR vs PATH; canary CI uses the latest conda-standalone onedir build.

Full changelogs: 3.15.0, 3.15.1

Changes in conda-pypi 0.5.0 / 0.6.0​

conda install conda-pypi=0.6.0

Notable changes (0.5.0):

• Test injection for conda pypi convert; --name-mapping for custom PyPI→conda name maps; fixes for headers wheels, hex wheel hashes (conda-rattler-solver compatibility), and data / scripts schemes.

0.6.0: repodata v3.whl test fixtures (extra_depends, normalized when); PEP 508 marker conversion for [when=…] entries; dependency fix for conda-package-streaming.

Full changelogs: 0.5.0, 0.6.0

We ❤️ our community​

Altogether, we had 8 new contributors this release cycle; thank you to all of our open source community members for helping make these improvements possible.

• @ELundby45 made their first contribution in conda#15716
• @crowecawcaw in conda#15636
• @lsoksane in conda#15549
• @shenhaofang in conda#15664
• @agriyakhetarpal in conda-content-trust#238 and conda-pypi#246
• @dbast in conda-content-trust#98
• @jaimergp in conda-content-trust#227
• @danyeaw in conda-build#5920
• @opoplawski in conda-build#5859
• @tombenes in conda-pypi#253
• @danpetry in conda-pypi#242

De facto standards​

The conda ecosystem is mostly founded upon the tooling initially built by Anaconda. Since Anaconda was the sole vendor, many aspects of the conda "standards" did not go through a process of design and standardization in the open; instead, they were probably deliberated internally by the responsible teams at the time. Excerpts of those decisions are sometimes captured in Github issues or pull requests, but not always.

As a result, the body of standards for the conda ecosystem has been dictated by the implementations found in conda/conda and conda/conda-build, among others. Reimplementations like mamba or rattler only had two things to guide their process: the source code and the behaviour of the existing tools. However, it was never clear which parts of the implementation were intentional or accidental (bug or feature?), leading to some ambiguity in their interpretation that in turn created an opportunity for drift.

That's why the conda community decided to implement an Enhancement Proposal system modeled after Python or Jupyter's process: CEPs (Conda Enhancement Proposals). This created the scaffolding needed to discuss and decide on policies and standards that affect the whole community. The CEPs system was successfully used by the community to innovate and address some design limitations of the original standards. In the last few years, we have seen new recipe formats and repodata distribution strategies. Unfortunately, the lack of formal standards meant that these innovative CEPs had to leave many details out of the document. For a person outside of the ecosystem, a sentence like "this field can take one or more MatchSpec strings" meant probably nothing. "What is a MatchSpec?" would be the only natural response... and we had no formal document for that!

Pay down the debt​

The only logical way to proceed was to roll up our sleeves and fill in the missing details, from the beginning. We took a look at how other ecosystems had addressed this issue and adopted many of their practices. The Open Container Initiative (OCI) specs and PyPA specifications were instrumental in this stage.

The first CEP we wrote (and approved!) in this direction was CEP 26, where we discussed what valid identifiers for packages and channels look like. This was the first time that the community was explicitly saying that unicode characters are not allowed in conda package names. Yes, conda-build would happily build ❤️-1.0-0.tar.bz2 for you.

While writing that CEP, we realized we had to leave many details out. We only went so far as to say which characters are allowed in a version string, but not how these strings are structured. We knew that opening that can of worms was a free ticket for quite the rabbit hole. But the only way is through, so there we went, and this is what happened:

After several months of writing and discussions, we started the final RFC (Request For Comments) period on January 28th. Two weeks later, on February 16th, we opened the voting period for two more weeks. The votes were counted on March 3rd, with the following results:

What's next​

The CEP numbers are somewhat arbitrary and don't necessarily allow for a structured reading of the specifications. Following PyPA's example, we will organize their content in the Learn > Specifications part of this website, trimmed to just the specification bits and leaving other details like rationale and motivation out. The idea is to have a single place where newcomers can quickly learn the details of what a valid package name is without having to parse through all the existing CEPs. This section will also aggregate the results of newer CEPs, should they supersede or extend the existing ones.

Most of the CEPs we passed simply codify what conda had already been doing for years. While this provides a much needed baseline, some of those legacy behaviors aren't necessarily ideal. In the future, we plan to refine these standards and deprecate outdated behaviors to keep the ecosystem lean.

But that is a goal for the next round. For now, let’s celebrate this milestone. A huge thank you to the steering council and everyone who contributed to the discussions!

Why this matters​

Ever wondered how many times a conda package has been downloaded? Which platforms are popular? Whether conda-forge or defaults drives more installs? condastats answers these questions with a single command:

condastats overall pandas --month 2024-01

Or from Python:

from condastats import overall
overall("pandas", month="2024-01")

The tool queries the Anaconda public dataset, a collection of monthly Parquet files containing download counts for conda packages since January 2017. Think of it as pypistats for the conda ecosystem.

The last release (0.2.1) shipped in August 2022. Since then, pandas 2.x changed its categorical handling, newer Python versions broke dask imports, and the build tooling around setup.py and versioneer became outdated. These releases catch up with all of that -- and then some.

Try it in the browser​

You can query conda download statistics right here -- no installation required. Enter a package name, pick a date range, and hit Query:

Open the full demo in a new tab for 15 curated example queries, shareable URLs, and more.

This runs Pyodide (CPython compiled to WebAssembly) directly in your browser with the real condastats package. It uses the pure-pandas query API introduced in 0.4.0, which doesn't require dask or s3fs -- making it lightweight enough to run in WebAssembly. Expect about 20 MB for Pyodide plus 1-15 MB of Parquet data per queried month.

What changed: 0.3.0 through 0.4.2​

Polished browser demo (0.4.2)​

The browser demo ships a full Python REPL (jQuery Terminal + Prism.js) with syntax highlighting, tab completion, and command history. It includes 15 curated example query cards, shareable URLs, and quick date range presets.

Pure-pandas query API (0.4.0)​

A new set of functions -- query_overall(), query_grouped(), and top_packages() -- operate on any pandas DataFrame without requiring dask or s3fs. This makes import condastats work in environments where dask isn't available (like Pyodide in the browser), while the existing S3-backed functions continue to work as before.

Dask is now lazily imported only when S3 functions are called, so the library starts up faster even in traditional environments.

Refactored codebase (0.3.0)​

The business logic has been extracted from cli.py into a dedicated _core.py module. All public functions now have type hints and NumPy-style docstrings. The CLI gained a --version flag, proper argument validation, and better error messages.

The build system migrated from setup.py + versioneer to pyproject.toml + setuptools_scm. Travis CI has been replaced by GitHub Actions, and Dependabot keeps dependencies up to date. The project now has 31 tests covering all CLI subcommands and the Python API.

Critical bug fixes (0.3.0)​

Several issues that made condastats unusable on recent Python and pandas versions have been resolved:

• TypeError: descriptor '__call__' on Python 3.11+ caused by an older dask version
• ValueError: Not all columns are categoricals (#19) when reading Parquet files
• ArrowStringArray requires PyArrow array of string type (#17, #24) from pandas/pyarrow version mismatches

If you tried condastats in the last couple of years and hit errors, these releases fix them.

Modern Python support (0.3.0)​

condastats now supports Python 3.10 through 3.14 and requires updated dependencies:

• numpy>=1.20.0
• pandas>=2.0.0
• dask>=2024.5.2
• pyarrow>=10.0.0

Python 3.8 and 3.9 are no longer supported.

Install and try it​

pixi global install condastats
condastats overall numpy --month 2024-06

conda install --channel conda-forge condastats
condastats overall numpy --month 2024-06

uv pip install condastats
condastats overall numpy --month 2024-06

pipx install condastats
condastats overall numpy --month 2024-06

Or run it without installing -- just pick your tool:

pixi x condastats overall numpy --month 2024-06

uvx condastats overall numpy --month 2024-06

pipx run condastats overall numpy --month 2024-06

Quick examples​

Compare multiple packages for a specific month:

condastats overall pandas numpy scipy --month 2024-01

Break down downloads by platform:

condastats pkg_platform pandas --month 2024-01

See monthly trends over a range:

condastats overall pandas --start_month 2024-01 --end_month 2024-06 --monthly

Group by conda channel (anaconda vs. conda-forge):

condastats data_source pandas --month 2024-01

All of these work as Python functions too:

from condastats import overall, pkg_platform, data_source

overall(["pandas", "numpy"], month="2024-01")
pkg_platform("pandas", month="2024-01")
data_source("pandas", start_month="2024-01", end_month="2024-06", monthly=True)

New documentation​

The documentation at condastats.readthedocs.io has been completely rewritten using the Diataxis framework, organized into four clear sections:

Get involved​

condastats is a conda-incubator project. Contributions are welcome:

• Try the browser demo: condastats.readthedocs.io
• Report bugs or request features: GitHub Issues
• Install it: conda install --channel conda-forge condastats or pip install condastats

Originally created by Sophia Man Yang, condastats is now maintained by the conda-incubator community.

Further reading​

• condastats on GitHub
• condastats on PyPI
• condastats on conda-forge
• Anaconda public dataset
• Full changelog

Changes in conda 26.1.0​

To update conda to the latest version, run:

conda install --name base conda=26.1.0

Notable Changes:

• Added support for Python 3.14.
• Added new --size flag to conda info --envs, conda env list, and conda list commands to display disk usage for environments and packages.
• Added --fix flag to conda doctor with health check fix capabilities.
• Added -s as a shorthand alias for conda run --no-capture-output and -O as an alias for --override-channels.
• Speed improvements: faster context initialization through caching condarc file reads, deferred PrefixData record instantiation, and faster conda run via inline environment activation.
• Added conda_package_extractors plugin hook to allow plugins to register custom package archive extractors.
• Added conda.cli.condarc.ConfigurationFile class for programmatic configuration file manipulation.
• conda run now properly deactivates the environment on exiting the command.
• Improved error messages for HTTP 403 responses and various platform-specific issues.
• Fixed parallel conda command failures on Windows by using GUIDs for unique temp filenames.
• Fixed conda clean --tarballs to also clean up .partial download files.

Check out the full changelog for more: 26.1.0

Changes in conda-build 26.1.0​

To update conda-build to the latest version, run:

conda install --name base conda-build=26.1.0

Notable Changes:

• Added support for CEP 28 (customizable system DLL linkage checks for Windows).
• Enabled echo on for Windows build scripts for better debugging visibility.
• Added riscv64 architecture support to the cdt() Jinja function.
• Fixed rpath handling on macOS to delete rpath before adding to avoid space errors.
• Fixed handling of unknown dynamic tags in liefldd.
• Fixed handling of empty source archives (now ignores and continues instead of failing).
• Bumped minimum conda version to 25.11.0 and conda-libmamba-solver to 25.11.0.

Check out the full changelog for more: 26.1.0

Changes in conda-pack 0.9.0/0.9.1​

To update conda-pack to the latest version, run:

conda install conda-pack=0.9.1

Notable Changes:

• Replaced deprecated pkg_resources with importlib.resources for better compatibility with modern Python.
• Added optional progress bar to conda-unpack for better user feedback.
• Fixed issue with extended path format on Windows.
• Fixed executables for all users.
• Updated Python supported versions.

Check out the full changelog for more: 0.9.0/0.9.1

We ❤️ Our Community​

Altogether, we had 8 new contributors this release cycle; thank you to all of our open source community members for helping make these improvements possible.

• @degerahmet made their first contribution in conda#14698
• @Bhanuu01 made their first contribution in conda#15554
• @barabo made their first contribution in conda#15418
• @gayanMatch made their first contribution in conda#15596
• @giacomo-ciro made their first contribution in conda#15428
• @matthewfeickert made their first contribution in conda#15622
• @pirzada-ahmadfaraz made their first contribution in conda#15602
• @vshevchenko-anaconda made their first contribution in conda#15376

Welcome to another quarterly update on what shipped in conda CLI and what we're building next. These posts complement our project board by pulling out the highlights and showing where your feedback matters most.

Highlights from Q4 2025​

A quick look at roadmap items shipped last quarter and available to try today. See previous update here.

Faster Performance with Sharded Repodata (Beta)​

What’s new: We released beta support for sharded repodata (CEP 16) in conda CLI, alongside support for the conda-forge channel on Anaconda.org. This means you can now enable sharded repodata in conda CLI and use it with conda-forge end-to-end for faster package metadata fetching!

What it does: Instead of downloading a single, large metadata file from each channel before solving, sharded repodata fetches metadata in smaller pieces as needed. On conda-forge, this results in roughly 10× faster metadata fetching and about 90% less bandwidth usage in benchmarked scenarios. Full benchmarks and technical details are available in the announcement blog post: https://conda.org/blog/sharded-repodata-improvements

How to try it:

Opt-in via conda CLI when using conda-forge:

• conda install --name base 'conda-libmamba-solver>=25.11.0'
• conda config --set plugins.use_sharded_repodata true

Pixi and rattler-build already use sharded repodata by default, no opt-in required.

Share feedback: We need your feedback before we can make sharded repodata the default in conda. If you try it and see performance improvements, great. If you hit regressions or edge cases, that's equally useful. Share what you're seeing on Zulip or open a GitHub issue.

Safer PyPI installs with conda-pypi plugin​

What’s new: The conda-pypi plugin is where our ongoing PyPI interoperability work is taking shape. The plugin provides a supported and explicit way to install PyPI packages inside conda environments. It's a safer alternative to the ad hoc pip install commands that everyone uses but that often leave environments fragile and hard to recover when something goes wrong.

What it does: The conda pypi subcommand makes PyPI package installs intentional and visible. It prefers conda packages for dependencies when they exist in configured channels, supports editable installs for development workflows, and respects the EXTERNALLY-MANAGED marker from PEP 668 to reduce accidental environment corruption.

How to get started: You can install the plugin and experiment with it now. Full documentation is available for supported workflows and usage.

This is actively evolving, and it's not production-ready yet! The real value of trying it now is helping us understand edge cases, behavior quirks, and whether these workflows actually fit how you work.

Share feedback: Please report issues or feature ideas on the conda-pypi GitHub repository.

What We're Building in Q1 2026​

These areas are active work in progress and will evolve as design and implementation continue.

Reproducible Environments with Native Lockfile Support​

What we’re working on: We're adding native support in conda CLI for working with lockfiles. This includes the ability to generate a lockfile from an existing environment and to create a new environment directly from a lockfile using conda.

Why this matters: environment.yml files describe intended dependencies, but recreating an environment requires solving against the current state of channels and metadata. Over time, or across platforms, this can lead to different results from the same input file. Run conda create six months later, on a different platform, or after channel updates, and you may get a different environment. Worse, it might fail to recreate at all.

Native lockfile support will allow conda users to recreate the exact same environment deterministically without re-solving, get identical results across machines, platforms, and points in time, use lockfiles as the source of truth for CI, production, and shared workflows, and work directly with common lockfile formats in the ecosystem, such as conda-lock and pixi/rattler.lock

Current status: This work is in progress. You can follow along and engage on our GitHub project board.

Support for Python Wheels in Repodata​

What we’re working on: We’re working on adding support for pure-Python wheels to conda’s package index (repodata). This work focuses on making metadata about Python packages from PyPI available to conda’s dependency solver, rather than introducing a new install workflow.

Why this matters: By representing Python wheels in repodata, conda can take these packages into account during solving. Instead of treating PyPI packages as opaque additions that happen outside of conda's model, conda can reason about them alongside conda packages. This means better conflict detection, more accurate dependency resolution, and a clearer picture of what's actually in your environment.

We're starting with pure-Python wheels because they're the most straightforward case. It's a focused scope that lets us validate the design and implementation before expanding further.

Current status: This work is active in Q1 and includes both design and implementation.

The proposed approach is described in a draft CEP, Repodata Wheel Support. Feedback on the design is especially valuable at this stage. Implementation progress and related discussion are tracked on our GitHub project board.

Get Involved!​

This roadmap update reflects work that is already underway, but priorities are always evolving based on community feedback. The most effective ways to get involved are:

• File GitHub issues when something doesn’t work as expected or when you have an idea for improvement
• Join conda community calls or participate in conversations on Zulip
• Contribute code, documentation, or reviews where you see gaps or opportunities

We’ll continue sharing progress through quarterly roadmap updates. If you have thoughts on what’s useful in these posts or what could be clearer, please let us know in this Zulip topic.

None of this work happens without the conda community. Thank you for your feedback, contributions, and patience as we build together.

Conda has long been the driver of data science workflows because of its unique ability to manage the complexities around Python packaging's diverse dependency requirements. It's precisely because of this that conda is also able to handle managing much more than just Python dependencies.

In this tutorial, we'll show the strengths of conda's flexibility and provide a guide on how you can install PostgreSQL for local development environments. Installing PostgreSQL this way offers several advantages: no root or admin permissions are required, the installation is isolated and reproducible, and your database can be version-controlled alongside other project dependencies—making it a lighter-weight alternative to container-based solutions like Docker.

Prerequisites​

Throughout this tutorial, we'll show you how to install and run PostgreSQL from conda-forge using conda, mamba (or micromamba), or pixi. Please refer to those projects' documentation for information on how to install them.

Setting up your environment​

To start, we'll create a new environment with the postgresql package.

conda create --name postgresql --channel conda-forge postgresql

mamba create --name postgresql --channel conda-forge postgresql

# Create your project directory first
mkdir postgresql
cd postgresql

# Initialize your pixi environment and add dependencies
pixi init
pixi add postgresql

pixi global install postgresql

Running PostgreSQL​

Now that we have our environment set up and packages installed, we can initialize our database and get it running. The postgresql package exposes the following commands that we'll use to do that:

• initdb
• createuser
• createdb
• pg_ctl

Creating a data directory​

The first thing we need to do is create the directory we'll use to store our data. For this example, we're going to create a "postgresql" directory in the home directory, but this could be anywhere you'd like:

mkdir ~/postgresql
initdb -D ~/postgresql

Starting the server​

Now that we have a location set for storing our data, we can launch the postgresql process by running the following command:

pg_ctl -D ~/postgresql -l ~/postgresql/logfile start

With -D, we pass it the location of our data directory and the -l option sets the file path that will receive postgresql's log output.

Creating a user and a database​

The next two commands will create a user account and database we can use for our application:

createuser user
createdb --owner user user

After this, your new database should be ready to accept connections. You can test this by running the following psql command:

psql -U user

Editing the configuration​

To make changes to how the server is configured, you can edit the default configuration that was created with the initdb command. The two most important files for postgresql's configuration are:

• pg_hba.conf: controls authentication
• postgresql.conf: all other configuration settings

For example, if you wanted to change the default authentication behavior of your postgresql server, you could edit the lines at the bottom of the pg_hba.conf to use password instead of trust:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     password
# IPv4 local connections:
host    all             all             127.0.0.1/32            password
# IPv6 local connections:
host    all             all             ::1/128                 password
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     password
host    replication     all             127.0.0.1/32            password
host    replication     all             ::1/128                 password

Afterwards, you would need to restart the server with the following command:

pg_ctl -D ~/postgresql -l ~/postgresql/logfile restart

Final thoughts​

We hope this gave you a good orientation on using PostgreSQL via conda! Installing PostgreSQL this way offers several practical benefits:

• No root permissions required: You can set up a full database server in user space.
• Reproducible environments: Include postgresql in your environment.yml or pixi.toml and share the same setup across your team.
• Lighter-weight than Docker: For local development, this approach avoids the overhead of running a container runtime.
• Version control friendly: Your database dependency can be locked alongside your application dependencies.

Because you can install PostgreSQL this way, it also opens up possibilities for bundling applications that use PostgreSQL with conda. If you want to extend this setup, consider adding packages like postgis for geospatial support or psycopg2 for Python database connectivity—all available from conda-forge.

Further reading​

• PostgreSQL Documentation — official documentation for PostgreSQL
• postgis on conda-forge — geospatial extensions for PostgreSQL
• psycopg2 on conda-forge — Python adapter for PostgreSQL
• Conda Ecosystem Explained — introduction to the conda ecosystem

AI agents reason well, but only with good data. conda-meta-mcp bridges the gap between frozen training data and live ecosystem metadata.

This article introduces conda-meta-mcp, an MCP server that exposes authoritative, read-only conda ecosystem metadata directly to AI agents. We'll explore the problem it solves, the tools it provides, and real-world workflows that demonstrate its power.

The Problem: Knowledge Cutoffs Meet Rich Metadata​

When you ask an AI agent about conda, you hit two walls:

Knowledge cutoffs. Models trained in mid-2024 know nothing about September releases, new conda features, or recent CVEs. They guess based on stale training data.

Inaccessible metadata. Even with web access, agents can't efficiently query the structured data embedded in conda packages: recipes, dependency graphs, run_exports, build provenance. This information is buried in package archives, not exposed through simple web APIs.

Consider these questions:

• "Is scikit-learn>=1.5 available on conda-forge for linux-64?"
• "What packages depend on numpy in conda-forge?"
• "Which conda package provides the cv2 Python import?"
• "What run_exports does openssl declare?"
• "Which package ships libcuda.so?"
• "Which feedstock commit bumped pyspark to version v4.1.0?"

These aren't reasoning failures. They're data access problems. AI agents reason well with good information. Without live, authoritative metadata, they can't solve real packaging problems reliably.

Enter conda-meta-mcp​

conda-meta-mcp is an MCP (Model Context Protocol) server that exposes authoritative, read-only conda ecosystem metadata directly to AI agents. The project is currently in incubation within the conda-incubator GitHub organization.

Instead of relying on stale training data, agents can now call structured tools:

The user doesn't need to know how to call MCP tools or when to use them. The LLM selects appropriate tools based on their descriptions and synthesizes results into human-readable answers.

Why Conda Metadata Is Uniquely Rich​

Every conda package embeds an info/ metadata tarball containing:

• Recipe and build scripts (meta.yaml/recipe.yaml, build.sh, bld.bat): source provenance, dependency declarations, build commands
• Rendered metadata (run_exports.json, index.json, about.json): resolved constraints, feedstock URL and commit SHA, CI job identifiers

This is far richer than what wheels or sdists provide. The embedded provenance enables auditable reproducibility: you can rebuild a binary from first principles using metadata stored in the package.

This same metadata powers conda-forge's migration infrastructure, the heavy machinery that builds dependency graphs and continuously rebuilds thousands of packages (as described in Part 3 of our conda series).

The Tools​

conda-meta-mcp exposes ecosystem knowledge through seven composable tools. Agents chain them to answer complex questions.

These tools fall into two categories: package discovery (finding and inspecting packages) and ecosystem navigation (understanding relationships and mappings). All tools are read-only and designed for efficient context usage.

Package Discovery​

package_search: Find Packages by Spec​

Search packages by spec, channel, and platform. Results ordered by newest version.

>>> package_search("scipy", channel="conda-forge", platform="linux-64", limit=1)
{"results": [{"version": "1.16.3", "url": "...scipy-1.16.3-py314hf5b80f4_1.conda"}], "total": 472}

package_insights: Deep Package Inspection​

Inspect a package's info/ tarball: rendered recipe, run_exports, source provenance. Foundation for SBOM generation and CVE analysis.

>>> package_insights(url="...openssl-3.6.0-h26f9b46_0.conda", file="info/run_exports.json")
{"info/run_exports.json": {"weak": ["openssl >=3.6.0,<4.0a0"]}}

Ecosystem Navigation​

These tools help agents understand relationships between packages, map across ecosystems, and navigate the dependency graph.

repoquery: Dependency Graph Navigation​

Query what depends on a package (whoneeds) or what a package depends on (depends).

>>> repoquery("whoneeds", "numpy", channel="conda-forge", limit=1)
{"query": {"total": 286778}, ...}

cli_help: Conda CLI Documentation​

Introspect conda's command-line interface dynamically. Supports regex filtering.

>>> cli_help(tool="conda", grep="create", limit=10)
"conda create: Create a new conda environment from a list of specified packages..."

import_mapping: Python Import to Package​

Map Python imports to conda packages. Essential for cross-ecosystem discovery.

>>> import_mapping("cv2")
{"best_package": "opencv", "candidate_packages": ["libopencv", "opencv", "opencv-python-headless"]}

pypi_to_conda: PyPI Name to Conda Package​

Map PyPI distribution names to conda equivalents. Handles the naming convention differences between ecosystems.

>>> pypi_to_conda("PyYAML")
{"pypi_name": "PyYAML", "conda_name": "pyyaml", "changed": false}

file_path_search: Find Packages by File Path​

Search for packages containing a specific file path. Useful for finding which package provides a specific binary or library.

>>> file_path_search("bin/conda", limit=5)
{"artifacts": ["cf/linux-64/conda-4.6.9-py36_0", ...], "total": 1000}

All tools support limit and offset for pagination. Most support get_keys for field filtering to protect agent context windows.

Real-World Workflows​

Cross-Ecosystem Package Discovery​

PyPI and conda use different naming conventions. An agent can resolve these mappings:

Understanding Ecosystem Impact​

Reviewing Dependency Updates​

When Renovate proposes a version bump, you want to know what actually changed beyond the version number. Did the maintainers add patches? Change dependencies? Modify build scripts?

The URL allows a user or agent to inspect in detail what was changed by whom.

CVE Analysis with Grype MCP​

Regulations like NIS2, DORA, and the Cyber Resiliency Act require organizations to track their software supply chain. The Grype MCP can scan conda environments for CVEs. When combined with conda-meta-mcp, agents can perform deeper analysis to determine if a CVE actually affects your code.

Here's a concrete example: an agent scans its own MCP server environment:

This deep analysis is only possible by combining multiple tools: Grype for CVE detection, conda-meta-mcp for package inspection, and code search for call graph analysis. A CVE scanner alone would flag the vulnerability without this context.

See also QuantCo's blog on conda regulation support for how syft consumes conda-meta/ files to generate SBOMs that standard CVE scanners can process.

Engineering: Built on Battle-Tested Foundations​

conda-meta-mcp wraps existing, proven conda ecosystem libraries with no wheel reinvention:

• conda_package_streaming.url.stream_conda_info(): Streams metadata from CDN (~100ms, no full download)
• conda.api.SubdirData.query_all(): Queries repodata.json using SAT solvers
• conda.cli.conda_argparse.generate_parser(): Exposes conda's CLI documentation dynamically
• conda_forge_metadata: Provides PyPI to conda and import to package mappings
• libmambapy: Powers repoquery with fast dependency graph traversal
• conda-forge-paths database: Powers file path search via Quansight's API

The server is built with FastMCP for minimal boilerplate and uses pixi for fast, reproducible dependency management.

Design Principles​

1. Read-only by contract: Never mutates environments. Safe to host publicly.
2. Context-aware: Pagination, filtering, and windowing protect agent context.
3. Fast startup: pixi's lockfile ensures reproducible, secure dependency fetch in seconds.

Getting Started​

See the conda-meta-mcp README for installation instructions covering Claude Desktop, Cursor, OpenCode, Zed, VSCode, and GitHub Copilot.

Outlook​

conda-meta-mcp is use case agnostic: it exposes ecosystem facts without judgment, and works with many AI agents. What will you build? CVE analysis, dependency audits, migration planning, compliance reporting? The examples in this post are starting points.

Share your prompts and use cases with the project:

• conda-meta-mcp on GitHub
• Open an issue or discussion with your discoveries

Happy experimenting!

Takeaway​

conda-meta-mcp solves a fundamental problem: AI agents can reason, but they need live, authoritative data to reason correctly about packaging. By exposing conda's rich embedded metadata through the Model Context Protocol, agents can now answer questions that were previously impossible without manual investigation.

The seven tools, from package_search to file_path_search, are composable building blocks. Agents chain them to perform cross-ecosystem discovery, dependency impact analysis, CVE triage, and supply chain auditing. The embedded provenance in every conda package makes this level of analysis possible.

As AI agents become more prevalent in development workflows, conda-meta-mcp ensures they have access to the same rich metadata that powers conda-forge's migration infrastructure. The result: agents that can make intelligent packaging decisions grounded in real ecosystem data.

Further Reading​

• Model Context Protocol specification
• Conda Ecosystem Explained
• Practical Power: Reproducibility, Automation, and Layering

• 2PM UTC
• 5PM UTC

The first meeting in 2026 will take place on January 7th, at 5PM UTC. For more details consult the calendar.

The meeting minutes will be available in both conda.org and conda-forge.org, in the usual places.

This is one of our first steps towards reducing the administrative duplication existing between these overlapping communities.

How do I try it out?​

If you're using conda-forge with conda and would like to try out this new feature, first update conda-libmamba-solver in your base environment and then opt in to the feature by setting plugins.use_sharded_repodata = true:

conda install --name base 'conda-libmamba-solver>=25.11.0'
conda config --set plugins.use_sharded_repodata true

Background and context​

In this section we provide some context around why we decided to develop this feature. We think it will help you to better understand the performance metrics, but if you already know the ins and outs of how conda stores and uses package metadata, feel free to skip ahead to the Performance improvements section.

What's repodata?​

Repodata is a conda specific term that refers to the package index that all conda clients must download in order to find and install available packages. The best way to think about it is as a database containing every package file, its dependencies, and other metadata for a particular channel.

Repodata challenge at scale​

Channels distribute repodata as a single file. As channels add more packages, that file grows. For channels with hundreds of thousands of packages, like conda-forge, that single file repodata becomes a bottleneck. It takes longer to download and requires more memory to parse. When anything in the channel updates, the entire cache invalidates. Conda re-downloads the complete file just to get the latest metadata. All of this leads to a slow experience for users.

Addressing this challenge​

There have been several attempts to address this problem over the past six years, including reducing the size of repodata.json and incrementally updating repodata by patching. Both of these previous attempts to make repodata fetching more efficient still weren't as performant as they could be. This led Bas Zalmstra and Wolf Vollprecht at prefix.dev to design and implement a new approach. Bas authored CEP 16, with input from the entire conda community, defining a new mechanism for fetching repodata using a sharded approach.

This approach works by splitting repodata into multiple "shards". Each package has its own shard which is much smaller than the complete repodata. So, when a package is installed, we only need to fetch what we need. This results in a much smaller download size and a faster overall experience.

Sharded repodata in the wider ecosystem​

CEP 16 was authored by Bas Zalmstra at prefix.dev, reviewed by the conda community, and approved by the conda Steering Council in July 2024. For a deep dive into the technical design and motivation, see the prefix.dev blog post on sharded repodata.

Since the CEP was approved, Pixi, rattler, and rattler-build have all provided production-ready implementations of sharded repodata. The prefix.dev channels have supported CEP 16 from day one, giving Pixi and rattler users the benefits of faster metadata fetching for over a year.

Now that anaconda.org also serves sharded repodata for conda-forge, even more users across the ecosystem will benefit. This is also great news for conda-forge maintainers using rattler-build: faster repodata fetching means reduced build times in CI.

This collaborative effort across multiple organizations, prefix.dev, Anaconda, Quansight, and the conda-forge community, demonstrates how the conda ecosystem can work together to deliver meaningful improvements for everyone.

Bringing sharded repodata to conda​

With CEP 16 already proven in production by Pixi and rattler, we've been doing the work needed to bring the same benefits to conda users.

• Earlier this year, we updated conda-index so channels can generate sharded repodata.
• Most recently, we added support in conda-libmamba-solver, now in beta, so the conda CLI can consume the new repodata format.
• The anaconda.org team at Anaconda, with contributions from Quansight, worked with the conda-forge community to enable hosting of sharded repodata. We plan to work with other channels to add support as the beta progresses.

With all this in place, conda-forge is now publishing sharded repodata, and conda will automatically find it if the feature is enabled.

In the next section, we share the performance improvements we've seen so far.

Performance improvements​

To compare performance between the sharded and non-sharded approach, we used two different environment creation scenarios: Python and Data Science. The Python scenario fetches the package python and all its dependencies, and the Data Science scenario fetches the packages, pandas, plotly and scipy and their dependencies. We benchmarked just the repodata fetching itself (check out the script we used here).

Furthermore, we ran our comparison using a cold cache where nothing was present in conda's cache and everything was fetched via network requests, and a warm cache where very few if any network requests were necessary.

To get a complete picture of how these changes affect conda, we not only measured total time but total network bandwidth usage and maximum memory usage.

Total time​

Below are the comparisons between non-sharded and sharded fetching measuring total time.

Total time with cold cache (seconds)​

Total time with warm cache (seconds)​

Key takeaways​

• Under both scenarios, we see a ten times speed-up in fetching and parsing of repodata
• This happens because the sharded repodata is significantly smaller

Network bandwidth​

To further illustrate the improvements, we show the total amount of megabytes downloaded with sharded versus the non-sharded approach.

Total network bandwidth (MB received)​

Key takeaways​

• The sharded approach reduces the amount downloaded by a factor of 35!
• Non-sharded fetching always has to fetch the same sized repodata but sharded repodata only fetches what it needs, meaning it varies based on the requested packages as seen here.

Max memory usage​

The last metric we examine is the maximum memory usage of sharded repodata fetching. Here, we just show the "cold" cache scenario.

Max memory usage (in MB)​

Key takeaways​

Both package scenarios see significant decreases in memory usage with a fifteen and and seventeen times reduction in memory usage.

Conclusion​

We're excited to see these numbers and think this will translate to a better overall experience for conda users! If you've read this far, we hope you're convinced to give the beta release a try and we welcome any feedback you may have. Please file an issue at the conda-libmamba-solver repository on GitHub to reach out to us.

Finally, we want to give a big shout out to the conda-maintainers team and specifically Daniel Holth for making the addition of this feature possible!

Changes in conda 25.11.0​

To update conda to the latest version, run:

conda install --name base conda=25.11.0

Notable Changes:

• Enhanced virtual packages plugin API with new fields for controlling override behavior.
• Added new override_virtual_packages (alias: virtual_packages) configuration key to .condarc for overriding virtual package versions and build numbers.
• Added created and last_modified properties to conda environments.
• Added new envs_details field to conda info --json output for inspecting properties of registered environments (also available via conda info --envs --json and conda env list --json).
• Fixed various bugs related to MatchSpec serialization, channel URL handling, and Python 3.14 compatibility.
• Improved warning for users attempting to add reserved environment variables like PATH to environment configurations.

Check out the full changelog for more: 25.11.0

Changes in conda-build 25.11.0​

To update conda-build to the latest version, run:

conda install --name base conda-build=25.11.0

Notable Changes:

• Added support for specifying a custom PyYAML loader when parsing configuration files via conda_build.variants.parse_config_file.
• Fixed BUILD environment variable to properly respect the cdt_name variant configuration. Previously, it was hardcoded to use cos6 or cos7 based on architecture.
• Fixed Windows MSVC version detection for Python 3.5+.
• Updated CMake generator handling for CMake 4 compatibility (CMake 2 support was dropped in CMake 4).
• Python 3.9 support has been removed. The minimum supported Python version is now 3.10.

Check out the full changelog for more: 25.11.0

Changes in conda-libmamba-solver 25.11.0​

To update conda-libmamba-solver to the latest version, run:

conda install --name base conda-libmamba-solver=25.11.0

Notable Changes:

• Added experimental support for CEP 16 sharded repodata (see announcement above).
• Added support for CEP 17 python_site_packages_path.
• Fixed the cpuonly mutex to correctly prevent CUDA packages from being installed, matching classic solver behavior.
• Added new messaging for when conda is outdated, environment is frozen, and conda-self is installed.
• Python 3.9 support has been dropped. The minimum supported Python version is now 3.10.
• Added codspeed benchmarking GitHub action and benchmarks.

Check out the full changelog for more: 25.11.0

We ❤️ Our Community​

Altogether, we had 7 new contributors this release cycle; thank you to all of our open source community members for helping make these improvements possible.

• @danyeaw made their first contribution in conda#15208
• @lang-m made their first contribution in conda#13165
• @hoxbro made their first contribution in conda#15325
• @sumanth-manchala made their first contribution in conda#14179
• @shermansiu made their first contribution in conda-build#5800
• @agriyakhetarpal made their first contribution in conda-libmamba-solver#741
• @stacynoland made their first contribution in conda-libmamba-solver#766

In Part 1, we explained why conda is not just another Python package manager. In Part 2, we placed conda in the broader packaging spectrum, showing how it differs from pip, Docker, and Nix.

Now we turn to what makes conda practical and powerful: reproducibility, automation, layered workflows, and rolling distribution.

Understanding conda's theoretical advantages is one thing. Seeing how they translate into real-world benefits is another. In this final article, we explore how conda's design enables teams to build reliable, maintainable software environments that scale from personal projects to enterprise systems.

We'll cover how conda packages encode provenance, how lockfiles ensure reproducibility across time and teams, and how intelligent layering with pip/npm gives you the best of both worlds.

Reproducibility built into the package format​

Conda packages are designed for traceability and rebuildability:

• Recipes included. Each conda package embeds the rendered recipe (meta.yaml or the newer recipe.yaml format) and build scripts under info/recipe. You can trace exactly how a binary was produced.
• Source provenance. Packages include upstream source URLs paired with either a SHA256 checksum (for releases) or the exact Git commit SHA (for git sources).
• Build environments captured. Unlike sdist or wheels, conda recipes describe not just Python dependencies, but the entire build environment: compilers, linkers, BLAS, CUDA, etc.
• Cross-platform parity. The same recipe can target Linux, macOS, and Windows, with platform-appropriate builds.

This level of transparency means you can always answer a critical question that's often impossible with traditional package registries:

"Where did this binary come from, and how was it built?"​

Most library registries give you a compiled artifact and little else. Conda packages give you a complete provenance chain from source to binary, making them uniquely suited for auditing, compliance, and reproducible science.

The info/ metadata tarball: provenance in every package​

Every conda package includes an info/ sub-archive with rich metadata:

• Original recipe files (meta.yaml or recipe.yaml, build/host/run sections, scripts)
• Rendered recipe → concrete versions + variants actually used in the build
• Source details → upstream URLs, checksums, commit SHAs
• Channel configuration (conda_build_config.yaml values in effect)
• CI/build references → build number, timestamps, feedstock (=recipe repository) URL and commit, and CI workflow run identifier

This means you can answer, for any binary:

• Which sources was it built from?
• Which toolchain, flags, and variants were active?
• Which CI job produced it?

Compared to a PyPI sdist or wheel, this is night and day. A wheel might tell you the package version. But a conda package lets you rebuild the binary from first principles using the embedded recipe and source reference.

That provenance is what enables conda packages' auditable reproducibility, critical for regulated industries, long-lived research, and enterprise compliance.

Why embedded metadata matters for security. Because this metadata lives within every package and isn't stored externally, it becomes immutable when combined with lockfiles. Locking a package hash in a lockfile cryptographically binds that specific package's entire metadata (recipe, sources, build details, checksums) to that hash.

This creates a tamper-evident record: if a supply chain attack or data manipulation occurs, the package hash would change, immediately alerting you to the compromise.

Automation with lockfiles and dependency update bots​

Reproducibility is only half the story: you also need automation to keep environments fresh.

Lockfiles: the foundation for reliability and reproducibility​

A conda lockfile captures exact versions of your entire runtime stack:

• Python/R interpreters
• Compilers
• BLAS, CUDA
• System libraries
• All packages (not just Python packages like poetry or uv.lock do)

This means you can rebuild your environment bit-for-bit years later, protecting against supply chain changes. Lockfiles provide three critical benefits:

1. Reproducibility: Rebuild identical environments across time, teams, and machines.
2. Supply chain security: Locked hashes verify package integrity and bind all embedded metadata (recipes, sources, build info) immutably to each package. If a supply chain attack occurs or metadata is manipulated, the hash changes immediately, providing forensic detection. You know exactly what you installed and can trace its provenance.
3. Reliability: No surprises from solver changes or package updates. Your environment stays stable until you explicitly update it.

For scientific projects, this is essential. Lockfiles preserve your computational environment over time: as long as the locked packages remain available on their channels, you can recreate the exact environment years later. Because the entire runtime is locked (not just application code), your 2024 research environment can be faithfully reconstructed in 2027 or beyond.

Lockfiles and conda​

While conda already has basic lockfile support, the ecosystem is actively standardizing lockfile formats via Conda Enhancement Proposals (CEPs). This ongoing effort enables different tools to support interoperable, standardized lockfile formats aligned across the entire ecosystem:

• conda-lock was the original lockfile implementation for conda, generating platform-specific lockfiles from environment.yml specs. It continues to play an important role for existing projects where migration effort isn't justified.
• pixi automatically updates the pixi.lock file, making lockfile-first workflows the default. With a dedicated team driving development, pixi is actively innovating with new lockfile formats and best practices, and is bringing these standards back to the broader conda ecosystem via CEPs.
• conda-lockfiles plugin (work-in-progress, coming to conda core soon) will provide enhanced native lockfile support directly in conda, supporting the newer standardized formats. This represents pixi's innovations being integrated into conda itself.

The goal is interoperability between clients: lockfiles created by one tool can be used by another. While this is already true for some formats (e.g., pixi-lock-v6), full standardization across all tools is still being defined and implemented through the CEP process.

Renovate integration: automated dependency updates with safety nets​

Renovate understands conda specs and lockfiles, enabling automated PRs to bump dependencies and regenerate lockfiles.

• Pixi: Full native support. Renovate automatically detects pixi.toml and pixi.lock, regenerating lockfiles on updates.

• Conda: Datasource support via the conda datasource. Teams can add custom regex patterns to their Renovate config to manage conda dependencies in environment.yml files (requires annotations like # renovate: datasource=conda depName=conda-forge/numpy). See Anaconda's Renovate config for a production-ready example of how to set this up.

  Important: When Renovate updates environment.yml, you'll need a workflow to regenerate the lockfile using conda-lock or similar tools so that CI/CD picks up the resolved dependencies.

Together, lockfiles and dependency update bots like Renovate enable iterative development with safety nets. Each pull request represents a small, testable change to your dependencies. As continuous integration systems typically run your full test suite on every update, they are proving in small steps that changes don't break anything.

Over time, this generates a constant stream of feedback about which dependencies are stable, which introduce subtle incompatibilities, and where your application is brittle. Combined with good tests, you learn more about your ecosystem, harden your app against breaking changes, and maintain confidence that your project evolves safely.

This is how teams build resilient, maintainable systems.

Conda as a rolling distribution: continuous evolution with stability​

Most operating system distributions (Debian, Ubuntu, Fedora) use a fixed-version model: each release has a defined lifecycle, and packages within that version remain largely unchanged (except for security patches). This provides stability but means users must perform major version upgrades to get newer software.

Conda takes a fundamentally different approach: it functions as a rolling distribution across all platforms (Linux, macOS, Windows) with constantly updated binary packages. New versions of libraries are released continuously, and the entire ecosystem evolves without waiting for major version releases.

Migration infrastructure: coordinated rebuilds at scale​

When a new, binary-incompatible version of a core library is released (like OpenSSL v4.0.0 expected in April 2026), channels like conda-forge automatically rebuild all dependent packages in the correct order.

This creates a gradual transition through the entire dependency graph by replacing one "plank" at a time. As one community member describes it, like an "ultimate Ship of Theseus", where bots constantly rebuild related packages, one dependency at a time. At scale, conda-forge, the largest community channel, manages 20+ independent migrations across its 26,000+ packages at any given time, making this orchestration industrial in scope.

This continuous rebuilding as new versions of core libraries are released enables conda environments to maintain ABI compatibility as dependencies evolve across Linux, macOS, and Windows, something traditional distros can't easily do. For a deeper exploration of the binary compatibility challenges that conda's model solves, see PyPackaging Native, which contrasts these issues with PyPI's approach.

Industrial-grade solvers​

This continuous rolling model is why conda needs powerful constraint resolvers like libmamba or resolvo. Every install must query extensive package metadata spanning multiple versions and build variants to determine which combinations satisfy all constraints using SAT-based algorithms.

Early conda users remember this as the primary complaint: installation took a long time. These concerns have substantially improved with modern solvers, and further improvements (like sharded repodata to reduce metadata downloads) are coming soon.

This rolling distribution model is one of conda's core strengths. You'll get the stability and coherence of a curated distribution system combined with the ability to stay current with upstream innovations. It's how conda environments can evolve safely over years while keeping dependencies fresh and secure.

Footprint and velocity in Continuous Integration and High-Performance Computing​

Not shipping glibc and friends lowers cold-start cost: creating, caching, and syncing environments is faster (and cheaper).

In these environments, conda provides:

• Smaller artifacts → quicker cache restores and less network churn
• Faster solves/installs → shorter feedback loops enabling rapid testing
• Easy per-project environments without admin rights → delightful user experience

This speed matters. In Continuous Integration, you want test feedback in minutes, not hours. In HPC, researchers need to spin up project environments quickly without waiting for administrators. In local development, fast environment creation means less context switching and more flow. Combined with lockfiles for reproducibility, conda delivers deterministic yet nimble environments that keep up with your workflow without heavyweight overhead.

The layering model: OS, conda, and language registries​

Conda fits into a complete 3-layer packaging stack:

1. OS layer: System package managers (apt, yum, etc.) Managed via base operating system or container base images (e.g., the ubuntu:24.04 base image). Provides the kernel, core C library (glibc on Linux), and fundamental system utilities. This layer is fixed when you choose your base image.

2. Distribution layer: Conda packages Provides Python, R, C/C++ libraries, GPU runtimes, compilers, and system-level tools, all solved together via a SAT-based solver. Built against the oldest supported OS runtime for forward compatibility. This is where the "distribution" concept from Parts 1 and 2 comes into practice.

3. Language registry layer: pip/npm Use pip (Python) or npm (JavaScript) on top to install application-level libraries, especially pure-language packages that don't introduce new compiled dependencies. Fast iteration for the final mile of your app.

Conda environments leverage all three layers intelligently:

• Container/VM provides the fixed OS baseline (layer 1)
• Conda solves for multi-language coherence and system dependencies (layer 2)
• pip/npm handles language-specific, pure-library iteration (layer 3)

This layering model gives you the best of all worlds:

• The stability and platform guarantees of a pinned base OS
• The robust, multi-language solving of the conda distribution system
• The fast iteration and ecosystem breadth of language registries

Real-world advantages for teams​

Conda’s design yields practical benefits across domains:

• Data science & ML.

  • Install GPU-enabled packages (tensorflow-gpu, pytorch) with the correct CUDA and cuDNN versions.
  • Combine them with Python packages (scikit-learn, transformers) and system tools (ffmpeg, graphviz) in one environment.

• Reproducible science.

  • Pin environment specs, generate lockfiles, and publish them alongside papers or datasets.
  • Ensure results can be replicated years later, even on newer operating systems.

• Enterprise automation.

  • Use dependency update bots (like Renovate) and lockfiles to enable iterative dependency updates with full test validation.
  • Each PR tests a small change. Over time, you build confidence that updates are safe and learn which dependencies are stable.
  • Run the same environment locally, in CI/CD, and in production.

• Developer onboarding.

  • New teammates run conda env create -f environment.yml (or similar command with mamba and pixi) and get a complete toolchain, not just a Python venv.
  • No system administrator required, no root permissions needed.

Beyond data science: DevOps with conda​

Conda environments aren’t just for scientific Python. The same distribution model also covers DevOps and platform engineering tools, e.g.:

• Kubernetes / Helm ecosystem: k3d, helm, helm-docs, chart-testing
• Infrastructure as Code: terraform, opentofu, packer
• CLI tools: ripgrep, fd-find, fzf, bat, eza, gitui, lazygit, jq, yq, just, htop

This means teams can manage application runtimes and infrastructure tooling with the same solver and reproducibility guarantees. Infrastructure updates follow the same iterative, tested workflow you'd use for application dependencies.

Automated PRs propose terraform updates, CI validates them thoroughly, and you learn incrementally which tool versions are stable. Instead of scattering scripts across system package managers or ad-hoc binaries, everything can be versioned and locked with conda, making DevOps workflows reproducible, portable, and CI-friendly.

Conda's unique position, revisited​

To summarize the series:

• Part 1: Conda ≠ PyPI: it's not a library registry, but a user-space distribution.
• Part 2: Conda's middle path: more powerful than pip/npm, lighter than Docker/Nix, and uniquely portable thanks to the libc boundary.
• Part 3: Practical power: reproducibility, automation, rolling distribution, and layered workflows that enable safe, iterative evolution over time.

The conda ecosystem is versatile, reproducible, and cross-platform. It actively evolves through community-driven innovation: newer tools like pixi experiment with new approaches, successful ideas are formalized via CEPs, and innovations flow back into core infrastructure. Migration infrastructure continuously rebuilds the entire ecosystem as core libraries evolve, maintaining stability while staying current. The ecosystem includes:

• Multiple tools (conda, mamba, pixi) supporting interoperable workflows
• Standardized lockfile formats being actively defined across tools via CEPs
• Innovation flowing from newer tools back into core infrastructure
• Linux, macOS, Windows support
• CPU and GPU stacks
• Multi-language environments
• All without root permissions

No other packaging system combines this breadth with this ecosystem maturity and innovation velocity.

Final takeaway​

The conda ecosystem is not just a package manager. It is a user-space distribution with rich metadata, a powerful solver, and a vibrant, evolving community.

By combining reproducibility, automation, rolling distribution infrastructure, and layering, the conda ecosystem (with tools like conda, mamba, and pixi) empowers individuals and teams to build, share, and maintain reliable software environments.

Through lockfiles and automated testing, you can evolve your dependencies safely. Small steps, validated by Continuous Integration, accumulate into resilient systems. The continuous migration and rebuilding of core libraries means your environments stay current without major version jumps. This frees teams to focus on what matters: building great software, not managing dependency logistics.

The conda ecosystem isn't pip. It isn't Docker. It's something better: a rolling distribution system designed for long-term stability through constant, tested change. Where traditional distros force you to choose between staying current or staying stable, conda gives you both: continuous evolution with coherence. It's how modern teams manage complexity across languages, platforms, and time.

Further reading​

This series dives deep into conda's concepts and architecture for readers familiar with packaging. For an introduction to the conda ecosystem, including the tools, channels, governance, and how to get started, see Conda Ecosystem Explained. It provides ecosystem context that complements the practices and patterns explored in this series.

In Part 1, we explained why conda is not just another Python package manager. Conda packages are distribution units, not libraries. Environments are essentially mini distributions in user-space.

“If conda is a distribution, where does it fit alongside other packaging systems like pip, Docker, and Nix?”​

This article places conda on the packaging spectrum, explains the concept of a distribution, and shows how conda’s design strikes a unique balance between flexibility, reproducibility, and accessibility.

What makes something a “distribution”?​

A distribution is more than a registry of libraries. It is a curated, versioned, and consistent collection of software packages designed to work together. A true distribution provides:

1. Completeness at build and runtime. Not just libraries, but compilers, headers, linkers, and runtime dependencies.
2. Policy and provenance. Standardized build flags, ABI compatibility guarantees, and source traceability.
3. A structured package format. Metadata that allows a solver to resolve complex dependencies.
4. Repackaging. Sources from many upstreams (PyPI, npm, GNU Savannah, GitHub, SourceForge, etc.) are rebuilt and normalized into the distro’s format.

This is what Debian, Fedora, and other OS distributions do and it’s also what conda does in user-space.

The libc boundary​

Here's a critical difference in how these systems treat the platform C runtime:

• Conda, depending on the operating system:

  • Linux: Ships nearly the entire user‑space stack (interpreters, libraries, toolchains) but intentionally reuses the host's glibc for forward compatibility.

  • Windows: Packages the MSVC runtime (vs2015_runtime, etc.).

  • macOS: Relies on system libSystem and frameworks.

• Containers (Docker/Podman): Typical base images bundle a userspace (including glibc or musl). Minimal images can start from scratch, but most workflows inherit a libc from the base layer.

• Nix: Provides its own glibc in the Linux /nix/store; on macOS it integrates with the platform libc while still isolating other dependencies.

• pip/npm: Distribute language-scoped artifacts only; assume system toolchains and the C runtime are already present.

Conda packages' approach keeps environments lighter while ensuring compatibility via conservative build baselines and virtual packages that encode host facts.

To ensure portability, conda packages are built against the oldest supported libc/OS runtime baselines, making them forward compatible across a wide range of newer systems.

Other user-space package managers, like spack and homebrew, also make their own decisions on packaging glibc depending on the platform, etc. And thus incur similar tradeoffs with respect to environment sizes.

Shared techniques with Nix: prefix-relocatability and patching​

Both conda packages and Nix instrument builds so binaries are prefix-aware and (in different ways) relocated:

• RPATH/RUNPATH patching so ELF binaries load from $PREFIX/lib
• Shebang rewriting so scripts execute with the environment's interpreters
• Mach-O (macOS) fix-ups (install_name_tool) for LC_LOAD_DYLIB/LC_ID_DYLIB
• ELF surgery via patchelf, which originated in the Nix ecosystem and is widely used by conda-build and rattler-build.

The result is the same idea in both worlds: build products that bind to their own prefix. In Nix, binaries are patched once to live under fixed, hash-addressed store paths like /nix/store/... (typically hashes of the derivation inputs and locked dependency graph, with pure content hashes used mainly for fetched sources) and are not meant to be moved afterwards, since changing the prefix effectively creates a new package identity and bypasses existing binary caches. In conda, binaries are typically built with a placeholder and relocated dynamically at install time into the environment prefix, so relocatable prefixes are a design objective there.

Why not shipping glibc keeps environments small (and portable)​

Conda's design philosophy of not shipping glibc (or the OS C runtime on Linux) has big consequences:

1. No base OS duplication. Containers and Nix closures ship libc, ld-linux, locales/NSS, and friends. That's tens to hundreds of megabytes before your app starts. Conda packages reuse the host libc, so that layer is never duplicated inside conda environments.

2. Fewer cascading dependencies. Pulling in glibc drags a constellation of tightly-coupled runtime pieces (dynamic loader, NSS, timezone/locale data). Leaving that to the host avoids pulling those into the conda user-space layer at all.

3. Security & updates. Host OS updates to glibc apply automatically across conda environments.

   The conda package managers (conda, mamba, pixi) enforce compatibility using virtual packages (e.g., __glibc>=2.17) and by building against the oldest supported glibc for forward compatibility.

4. Still safe and predictable. The solver includes the host fact (__glibc, __osx, __win) so you cannot accidentally solve to an incompatible set.

Conda vs. Pip, Docker, and Nix​

Let’s place them side by side:

The conda ecosystem's scope is not limited to scientific computing. Channels also package systems and DevOps tooling (e.g. ripgrep, terraform, helm) alongside Python/R/C++ stacks, as we'll explore in Part 3. This breadth is part of what makes conda a true multi-language distribution.

Conda’s “middle path”​

The conda ecosystem occupies a sweet spot in the packaging spectrum:

• Compared to pip/npm: conda packages handle native dependencies (BLAS, CUDA, compilers, system libs) and multi-language stacks. Pip/npm cannot.
• Compared to Docker: conda environments are lighter, faster to create, and usable without root privileges, while still providing consistency. You can still put a conda environment inside a Docker container when you need isolation.
• Compared to Nix: the conda ecosystem is more approachable and cross-platform. Nix provides stronger whole-system reproducibility, but the typical multi-user setup involves an initial system-level installation step (e.g. creating /nix and configuring the store/daemon) and comes with a steeper learning curve. Conda works out of the box on Linux, macOS, and Windows entirely in user space.

The conda ecosystem is thus best seen as a user-space distribution that balances power and accessibility. This balance is exemplified by its approach to portability through virtual packages.

Portability via virtual packages​

The conda package managers (conda, mamba, pixi) also have a unique mechanism: virtual packages. These reflect facts about your host machine and influence the solve.

• __glibc → glibc version (Linux)
• __osx / __win → macOS or Windows versions
• __cuda → CUDA GPU driver version
• __archspec → CPU microarchitecture details for optimization
• __linux / __unix → platform family indicators

These aren’t installed files, they’re ephemeral host facts injected into the solver. They constrain solutions for compatibility while keeping prefixes relocatable across machines that share the same baseline characteristics.

Takeaway​

The conda ecosystem sits in the middle of the packaging spectrum, not a language registry like PyPI/npm, not a container runtime like Docker, and not a full system package manager like Nix, but something uniquely useful in between.

Here's why:

• Lighter than Docker and Nix
• More powerful than pip/npm
• Portable and forward compatible thanks to careful build policies and the libc boundary

That's why conda feels like a distribution, because it is one, in user-space.

Up Next: Part 3 — Practical Power: Reproducibility, Automation, and Layering​

In the final article, we'll dive into how conda's model translates into real-world advantages: reproducibility, provenance, automation with lockfiles and automated updates with Renovate, and the layered workflow of combining conda with pip/npm.

This is the first article in a three-part series exploring the fundamental differences between conda and PyPI, and why understanding these differences matters for your development workflow. Conda is not just another Python package manager—it's a multi-language, user-space distribution system. In this series, we'll unpack what that means, explore where conda fits in the broader packaging landscape (alongside pip, Docker, and Nix), and show you how to think about conda's role in your toolchain.

Part 1 (this article) clarifies why conda is a distribution, not a package registry, and what that distinction means in practice.

When people first encounter conda, the most common misconception is:

“Isn’t conda just another Python package manager, like pip?”​

The short answer: no.

The differences start with the package collections that these tools draw from. PyPI (and npm, RubyGems, Cargo, etc.) are language-specific library registries.

The conda package ecosystem (installable with tools like conda, mamba, micromamba, or pixi), on the other hand, functions as a multi-language, user-space distribution that can assemble coherent runtime and build environments across programming languages, system libraries, compilers, and tools.

This first article sets the stage by exploring the difference between library registries and distributions.

To use an analogy: pip is like a car stereo—it requires a system to plug into—whereas conda is like the whole car, a complete, self-contained system.

What is a language-scoped package registry?​

A language-scoped package registry is a centralized catalog of packages for a single language ecosystem. Examples include:

• PyPI (Python Package Index): source distributions (sdist) and binary wheels (.whl) for Python packages.
• npm: registry of JavaScript/Node.js packages.
• RubyGems, CPAN, Cargo, and others.

These registries share common traits:

• They distribute language-scoped packages (source dists and wheels). Wheels can bundle compiled extensions and some native libraries, but they don’t attempt to model an entire multi-language runtime or toolchain.
• They rely on the host system to provide compilers, headers, and native dependencies.
• Their metadata is scoped to one language (e.g., install_requires in Python).
• They don’t aim to describe a full build environment.

This works well for pure libraries. Installing a package like requests from PyPI via pip is trivial, as it has no system-level dependencies.

What is conda?​

Conda is fundamentally different. It is better understood as a user-space distribution, not just a package manager:

• Multi-language scope. Conda packages include Python, R, C, C++, Fortran libraries, GPU runtimes, CLI tools, and even compilers.

• Prefix replacement. Binaries and shared libraries inside a conda environment resolve against the environment’s prefix ($PREFIX/...), not /usr/... from the host.

  This is achieved through relocation (e.g. rpath / runpath settings, patched shebangs, and text/binary rewriting performed during build).

• Solver-driven consistency. Conda package managers use SAT-based dependency solvers (e.g. libmamba, rattler) to ensure all dependencies—across languages, ABIs (Application Binary Interface), and platforms—work together coherently (see also Boolean satisfiability).

• Build + runtime. Recipes declare build/host/run phases so resulting packages accurately encode runtime and (when relevant) linked toolchain requirements.

• Portability. By convention, Conda packages are built against the oldest supported glibc (GNU C Library) or corresponding macOS/Windows baselines so they remain forward compatible with newer OS versions.

Put simply: conda packages model distribution units (self-contained, relocatable bundles of binaries, libraries, headers, data, and metadata), not just language-scoped libraries.

It is more like a system package manager, such as apt, yum, or dnf, except that you don't need root to administer or run conda packages, and many different package configurations can be used simultaneously in different environments.

Not just binaries: FHS-like user space inside environments​

Conda environments aren’t only bin/ and lib/. Because the prefix behaves like a chroot-style, FHS-inspired root (subset only; no /dev, /proc, etc.), packages can also install:

• bin/ → Executable entry points (interpreters, CLIs, entry-point shims)
• conda-meta/ → Per‑package JSON records (exact provenance + reproducibility)
• etc/bash_completion.d... & share/zsh/site-functions/... → shell completions
• fonts/... → fonts (useful for plotting, LaTeX, GUI stacks)
• include/ → headers for C/C++/Fortran development
• lib/ → Shared libraries, Python stdlib + site-packages/, compiled extensions, BLAS (Basic Linear Algebra Subprograms), compression, crypto, etc.
• lib/pkgconfig/*.pc → pkg-config metadata (pkg-config)
• share/ → Arch‑independent data: licenses, terminfo, locales, Jupyter kernelspecs
• share/man/... → manpages for CLI tools
• ssl/ → (Sometimes) CA cert bundle + OpenSSL config
• sbin/ → Ancillary / admin-style utilities (often sparse)

This is what “user-space distro” means in practice: complete developer and runtime assets live inside the environment, not scattered across /usr.

The core distinction: libraries vs. distributions​

Think of it this way:

• A library registry (like PyPI/npm) is about sharing code libraries within one programming language.
• A distribution (like Debian, Fedora, or conda) is about building coherent systems of software that interoperate reliably.

Conda environments are essentially miniature user-space distros, tailored to your workload. They carry everything needed for reproducible builds and executions—except for the platform’s core C library layer:

• On Linux, purposefully relies on the host’s glibc baseline for forward compatibility while shipping most other critical runtime components (libstdc++, compression libs, math libs, etc.).
• On Windows, the MSVC runtime is provided as conda packages (e.g. vs2015_runtime).
• On macOS, system frameworks and the platform libc are used.

This approach predates and inspired Python's manylinux wheel strategy. In fact, the manylinux policy was based on practices pioneered by conda through Enthought Canopy and Anaconda—both build against a conservative baseline so binaries function on newer systems.

Why forward compatibility matters​

One of conda’s design principles is building for the future:

• Packages are compiled against the oldest still-supported glibc (or macOS / Windows runtime versions).
• This ensures that binaries remain forward compatible with newer OS versions.
• For example: a package built against glibc 2.17 (from CentOS 7) will run on modern Linux distributions with newer glibc versions.

This forward-compatibility strategy is why conda environments are portable across diverse systems (within the same CPU architecture and compatible driver/toolchain constraints), from HPC clusters to modern laptops.

Why the confusion persists​

Conda is popular in the Python ecosystem, so many users encounter it as “that thing for installing numpy faster than pip.” But that framing hides its true nature:

• pip (the Python package installer, defaulting to the PyPI index) installs Python packages (sdists or wheels).
• Conda installs multi-language distro packages—some of which happen to be Python libraries.

The distinction matters: compilers, BLAS, and system-level dependencies are crucial to environment consistency, even when users don't directly think about them. pip and npm hope these dependencies are already available on your system.

Conda ensures they're present, compatible, and consistent across your entire environment. This distinction becomes most obvious when you need explicit control—such as choosing a specific BLAS implementation or building cross-language stacks—where pip/npm simply can't help you.

Takeaway​

The conda ecosystem (its package collections, formats, and installer tools) is fundamentally not PyPI, and it's not trying to be.

Where PyPI and npm are focused on sharing libraries within a single language, conda is about assembling complete, reproducible user-space distributions across languages, compilers, and platforms using a SAT-based dependency solver.

That’s why conda environments can run complex stacks like numpy + scipy + ffmpeg + graphviz + CUDA, all solved together, without relying on your system administrator or distro package manager.

Up Next: Part 2 — Conda in the Packaging Spectrum: From Pip to Docker to Nix​

In the next article, we’ll explore where conda fits in the broader packaging world—how it compares to pip, Docker, and Nix, and why its unique approach makes it the “middle path” between language registries and containers.

With any large open source project, dozens of pull requests and issues are always in flight, which can make it hard to see the bigger picture. Starting this quarter, we will publish regular roadmap updates to give you a clear view of what the conda maintainers team from Anaconda and Quansight, together with the broader community, is building and what you can expect.

The Q4 2025 roadmap highlights the features we are focused on delivering this quarter and early next year. These priorities came directly from community feedback across GitHub, forums, and events, and the roadmap will continue to evolve as new needs emerge.

Don’t see something specific on the roadmap? Let us know by opening an issue, or help us out by submitting a contribution via a pull request!

Q4 2025 Roadmap Priorities​

Faster Performance with Sharded Repodata Support​

What we heard: Installing or updating packages can be slow because conda downloads a single large index of all available packages, even if you only need a small part. This affects users of conda-forge even more because that package index is especially large . This leads to delays in local workflows, CI pipelines, and on slower networks.

What we are working on: We are implementing support for sharded repodata, as proposed and accepted in Conda Enhancement Proposal (CEP) 16. Instead of fetching one massive file, conda will be able to download smaller, targeted shards of metadata. This type of repodata fetching has already been implemented in the pixi package manager, and you can view the compelling improvements they have delivered in this blog post.

How you will benefit: Package installs and updates will complete faster, conda will feel more responsive in daily use, and automated workflows like CI will run more efficiently with reduced bandwidth costs.

Better Integration with the PyPI Ecosystem​

What we heard: Sometimes the package you need exists only on PyPI. Many users fall back on pip install inside a conda environment, but this approach often leads to dependency conflicts or broken environments that can take hours to fix.

What we are working on: We are working on better integration with the PyPI ecosystem through the conda-pypi plugin. This work focuses on providing a safer way to use conda to access and install pure Python packages distributed as wheels within conda environments, while laying the foundation for broader and more native integration in the future.

How you will benefit: This plugin will offer a safer path than mixing pip and conda directly, reducing environment breakage and making it easier to try packages that are not yet available on conda channels.

More Consistent Handling of Dependency Definition Files [stretch goal]​

What we heard: Conda can create environments from files such as environment.yml and requirements.txt, but the current handling of these formats has grown inconsistent over time. For example, conda create --file requirements.txt and conda env create -f environment.yml behave differently. While both commands work, the overall experience isn’t optimized for the variety of input formats users rely on today.

What we are working on: As a stretch goal for Q4, we plan to continue the refactor of how conda reads and processes environment definition files under a plugin-based system. This work aims to make file-based environment creation more consistent and to establish a cleaner foundation for supporting multiple input formats.

How you will benefit: The refactor will make environment creation feel more predictable across commands and file types. For contributors, the plugin architecture will make it easier to extend conda with new environment specification formats, such as support for defining dependencies with pyproject.toml in the future.

Looking Ahead​

We will continue posting roadmap updates each quarter and will expand the horizon to cover 6–12 months as our planning process matures. Our goal is to make conda development more predictable and transparent. Each update will show progress on current priorities and preview what is next, shaped by your feedback and contributions.

You can track progress live on the GitHub roadmap board, where you will find current status, upcoming milestones, and discussions on specific features.

Shape Conda’s Future With Us​

Conda is a community project, and these roadmap priorities reflect your input. Here are ways to influence what comes next:

• Share your feedback: File GitHub issues when conda does not work as expected or you have an idea for improvement
• Join the conversation: Conda community calls are where we discuss priorities, propose solutions, and decide what matters most
• Connect with maintainers: Find us on Zulip and the Discourse forum to troubleshoot, suggest features, or just learn more about our thinking
• Take the Python packaging survey: Every response helps us better understand your needs
• Contribute to conda or even become a maintainer yourself!

Thank you for choosing conda and being part of the community.❤️ Your feedback helps us build an ecosystem that fits your needs.

The main reasons are inactivity and the required maintenance efforts to moderate spam messages. The forums will still be available for consultation, but no new messages will be posted. See you in Zulip!

Changes in conda 25.9.0​

To update conda to the latest version, run:

conda install --name base conda=25.9.0

Notable Changes:

• Added two new health checks to conda doctor:
  • Check for ill-formed pinned file.
  • Check whether file locking is supported.
• Prevented renaming an environment currently listed as the default_activation_env.
• Added a new environment specifier, cep-24. This is a stricter version of the environment.yml format that enforces specific requirements and can be used when creating an environment from a file, e.g., conda env create --file FILE --environment-specifier cep-24.
• Updated environment model to support multiple platforms. This allows conda export --format FORMAT to support exporting multiple platforms at once.
• Annotated frozen environments in conda env list.
• Various deprecations were made.

Check out the full changelog for more: 25.9.0

Changes in conda-build 25.9.0​

To update conda-build to the latest version, run:

conda install --name base conda-build=25.9.0

Notable Changes:

No major changes to report. We just removed some deprecated code according to our deprecation schedule and made corrections to documentation.

Check out the full changelog for more: 25.9.0

We ❤️ Our Community​

Altogether, we had 7 new contributors this release cycle; thank you to all of our open source community members for helping make these improvements possible.

• @zeyugao made their first contribution in conda#14660
• @jcazevedo made their first contribution in conda#15140
• @nblair made their first contribution in conda#15037
• @lrandersson made their first contribution in conda#15249
• @ColemanTom made their first contribution in conda-build#5774
• @jsmolic made their first contribution in conda-build#5792
• @roryyorke made their first contribution in conda-build#5772

Changes in conda 25.7.0​

To update conda to the latest version, run:

conda install -n base conda=25.7.0

Notable Changes:

• Enhanced conda export command now supports plugin-based architecture with multiple output formats: yaml, json, and txt.
• Add automatic export format detection based on filename patterns (e.g., environment.yaml, explicit.txt, requirements.txt)
• Add "environment consistency" health check to conda doctor.

Check out the full changelog for more: 25.7.0

Changes in conda-build 25.7.0​

To update conda-build to the latest version, run:

conda install -n base conda-build=25.7.0

Notable Changes:

No major changes to report. We just removed some deprecated code according to our deprecation schedule.

Check out the full changelog for more: 25.7.0

Changes in constructor 3.12.2​

To update constructor to the latest version, run:

conda install -n base constructor=3.12.2

Notable Changes:

• Added support for conda init --condabin, mamba's mirrored channels, and the faster onedir variant of conda-standalone.
• EXE installers: fixed a permission issue for all-user installations for noarch package entry points.

Check out the full changelog for more:

• 3.12.0
• 3.12.1
• 3.12.2

Changes in menuinst 2.3.1​

To update menuinst to the latest version, run:

conda install -n base menuinst=2.3.1

Notable Changes:

• Bug fix: shortcuts are now only created for platforms explicitly enabled in the metadata.
• Added support for the new activation behavior of conda on Windows.

Check out the full changelog for more:

• 2.3.0 (full release notes with new features)
• 2.3.1 (patch release)

We ❤️ Our Community​

Altogether, we had 2 new contributors this release cycle; thank you to all of our open source community members for helping making these improvements possible.

• @IsabelParedes made their first contribution in constructor#1008
• @mmc1718 made their first contribution in conda#15025