Skip to main content

Conda ≠ PyPI: Why Conda Is More Than a Package Manager

· 8 min read
Daniel Bast
Daniel Bast
Open Source Contributor
Jannis Leidel
Jannis Leidel
Steering council member
Banner image for Conda ≠ PyPI: Why Conda Is More Than a Package Manager blog post

Part 1 of our series "Conda Is Not PyPI: Understanding Conda as a User-Space Distribution".

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.

Definition

A user-space distribution is a curated, relocatable filesystem prefix containing interpreters, libraries, headers, data, and tooling that runs entirely without needing privileged installation into system directories. It complements—rather than replaces—the host kernel and core C library.

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.

A note on wheels

Wheels (.whl) can bundle compiled extensions and some native libraries, but remain Python‑scoped: they don’t model a full multi‑language runtime, compilers, or cross‑language/system dependency metadata.

Community work (e.g. WheelNext) is adding capabilities (better hardware/microarchitecture tags, symlink support, richer native metadata)—complementary to, not a replacement for, the broader environment modeling of conda packages.

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.