PyPI mapping only works for Conda-Forge

[avcopan]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

Commands I ran and their output:

pixi run python -c "import lower_level_package; lower_level_package.greet()"
# Traceback (most recent call last):
#  File "<string>", line 1, in <module>
#    import lower_level_package; lower_level_package.greet()
#    ^^^^^^^^^^^^^^^^^^^^^^^^^^
# ModuleNotFoundError: No module named 'lower_level_package'

pyproject.toml file (goes along with pixi.toml file below):

[project]
name = "higher-level-package"
version = "0.0.0"
authors = [{name = "Andreas V. Copan", email = "avcopan@uga.edu"}]
requires-python = ">= 3.12"
dependencies = [
    "lower-level-package>=0.0.0",
]

[build-system]
build-backend = "uv_build"
requires = ["uv_build"]

pixi.toml file:

[workspace]
channels = ["conda-forge", "avcopan"]
platforms = ["linux-64", "osx-64", "osx-arm64"]
preview = ["pixi-build"]

[dependencies]
higher-level-package = { path = "." }

[package]
name = "higher-level-package"
version = "0.0.0"

[package.build]
backend = { name = "pixi-build-python", version = "*" }

[package.build.config]
ignore-pyproject-manifest = false
ignore-pypi-mapping = false

pixi info output:

System
------------
       Pixi version: 0.67.2
        TLS backend: rustls
           Platform: linux-64
   Virtual packages: __unix=0=0
                   : __linux=6.6.87.2=0
                   : __glibc=2.39=0
                   : __cuda=12.0=0
                   : __archspec=1=skylake
          Cache dir: /home/avcopan/.cache/rattler/cache
       Auth storage: /home/avcopan/.rattler/credentials.json
   Config locations: No config files found

Global
------------
            Bin dir: /home/avcopan/.pixi/bin
    Environment dir: /home/avcopan/.pixi/envs
       Manifest dir: /home/avcopan/.pixi/manifests/pixi-global.toml

Workspace
------------
               Name: higher-level-package
      Manifest file: /home/avcopan/code/misc/pixi-high-low-example/higher-level-package-attempt1/pixi.toml
       Last updated: 05-05-2026 13:09:30

Environments
------------
        Environment: default
           Features: default
           Channels: conda-forge, avcopan
   Dependency count: 1
       Dependencies: higher-level-package
   Target platforms: osx-arm64, linux-64, osx-64
    Prefix location: /home/avcopan/code/misc/pixi-high-low-example/higher-level-package-attempt1/.pixi/envs/default

Other files (e.g. script files, source files, etc.):

higher-level-package-attempt1-main.zip

Issue description

I am running into some issues in using pixi-build to develop a package along with its dependency. This is a minimal reproducer for the first issue I encountered.

Issue: When using the PyPI mapping functionality, I am able to map packages that exist on Conda-Forge, but for packages that exist on other channels, Pixi silently fails to find them. In this example, I created a package on PyPI (which I promise to remove) and on my Anaconda.org channel. I added it as a PyPI dependency in pyproject.toml and set ignore-pypi-mapping = false. Attached is the repository.

Expected behavior

I would expect Pixi to be able to find the lower-level-package, since I have specified "avcopan" as a channel. I would also expect Pixi to raise an Error if it couldn't find the dependency. Currently it silently fails.

Note that adding lower-level-package to the dependencies in the pixi.toml file as well does fix this issue, but in that case I no longer have a single source of truth and the PyPI mapping isn't doing anything.

[baszalmstra]

Mapping packages is difficult and we only currently map the packages on conda-forge. Through https://github.com/prefix-dev/parselmouth . You are correct that packages not from conda-forge are not automatically mapped.

I think the best we can do for now is to error when a pypi requirement has no matching conda package. It would force users to add those dependencies explicitly. What do you think @ruben-arts ?

[ruben-arts]

I was actually already expecting a warning through this:

pixi/crates/pixi_build_python/src/pypi_mapping.rs

Lines 426 to 449 in bd5014b

	// Get the mapping
	let lookup = match self.get_mapping(req.name.as_ref()).await {
	Ok(l) => l,
	Err(MappingError::PackageNotFound(_)) => {
	tracing::warn!(
	"PyPI package '{}' has no conda-forge mapping, skipping",
	req.name
	);
	continue;
	}
	Err(e) => return Err(e),
	};
	// Extract the conda package name
	let conda_name_str = match Self::extract_conda_name(&lookup) {
	Some(n) => n,
	None => {
	tracing::warn!(
	"No conda package names found in mapping for '{}', skipping",
	req.name
	);
	continue;
	}
	};

Not sure why that doesn't bubble upwards.

Next to that I would propose to allow for a custom mapping in the short term as a work around. e.g.:

[package.build.config.pypi-conda-mapping]
pypi-dep = "conda-dep"

We could also do some custom simple name comparison to all channels that are used in the workspace. Where we do only direct name to name checks. This is vulnerable but probably a "better than nothing".

[avcopan]

Thanks for the fast response! The simple name mapping would be convenient, because it would avoid the need to increment dependency versions in two places. Absent that, it would be useful to have some warning that the mapping didn't work -- if there is a way to get those error messages through to the user, for example.

Thanks for looking into it! Y'all are the best!

[ethanbb]

I think I'm missing something - if a package doesn't exist on conda-forge, but does on PyPI, shouldn't it be automatically added to the pypi-dependencies of whatever workspace depends on it (either directly, as in this example, or even if one was installing "higher-level-package" as a source dependency of another workspace, which is my use case)? I thought the idea behind this feature was to automatically install everything possible from conda-forge, and the rest from PyPI.

For now I can add it manually as a workaround.

[tdejager]

Hey just to make it a bit clearer to navigate the mapping although it wont help this issue per-se we have created a small dashboard to explore how some packages have been mapped: https://prefix-dev.github.io/parselmouth/

[kaiserls]

I have a similar issue. I tried patching the conda-pypi-mapping using a custom file, extended with my own packages, but the mapping never works. Actually it seems like my file is never loaded. Can someone provide a working example using a custom conda-pypi-map? Possibly related to #2562.

[dhirschfeld]

Also running into this now I'm starting to investigate pixi build

[package.build.config.pypi-conda-mapping]
pypi-dep = "conda-dep"

☝️ something like that, that you could manually specify for your internal packages which worked in addition to the default conda-forge map would be useful I think.

[ruben-arts]

@tdejager is working on this with #6333