compressed mapping should map to more than one pypi name

[nichmor]

Right now our compressed mapping can have only null or one pypi name.
Cases like this prefix-dev/pixi#771, which require more than one name are not properly handled using our mapping.

[ruben-arts]

An example we're I'm testing the mappings is this project: https://github.com/eightysteele/pixi-panic/blob/master/pixi.lock

The nvidia packages should not be installed by uv. So I was trying to missuse the mapping to move all the nvidia package under one of the conda nvidia packages. But I wasn't allowed.

[maresb]

Excellent that you're already on top of this!

I want to point out that rather than picking a particular direction and considering this as a conda-forge → PyPI mapping or as a PyPI → conda-forge mapping, it's also possible to take a symmetrical view.

Mathematically, "conda-forge package $c$ includes PyPI package $p$" is a relation. The agnostic way of handling this is to create a big table of pairs $(c, p)$. Then in order to produce either the you group by either conda-forge or PyPI. So in pseudocode,

includes_relation: set[tuple[str, str]] = set()

for c in cf_packages:
    for p in get_pypi_packages(c):
        includes_relation.add((c, p))

cf_to_pypi: dict[str, set[str]] = defaultdict(set)
for c, p in includes_relation:
    cf_to_pypi[c].add(p)

pypi_to_cf: dict[str, set[str]] = defaultdict(set)
for c, p in includes_relation:
    pypi_to_cf[p].add(c)

# Of course they're all equivalent, and easy to go back:
reconstructed_includes_relation: set[tuple[str, str]] = set()
for p, c_set in pypi_to_cf.items:
    for c in c_set:
        reconstructed_includes.add((c, p))

Whether or not you actually implement this, I personally find it really helpful to simply be aware of this perspective in order to help avoid making logical errors.