Challenging one-to-one, name-to-name correspondence with some examples

[jaimergp]

There are a few PyPI packages (specially in the CUDA ecosystem) that map to more than one conda spec. And I say 'spec' and not 'name' because sometimes you need a particular version.

• PyPI's PyQt5 -> conda's pyqt=5
• PyPI's cupy-cuda12x -> conda's [cupy, cuda-version=12].

AFAICT, the current mappings only do name -> name. Any chance we could expand that? It might require manual annotation on top of the auto heuristics :/

[nichmor]

hey @jaimergp !
Good question!

Currently we record multiple names and it's versions that are present in source. For example, https://conda-mapping.prefix.dev/hash-v0/4608b9caafc4fa16d887f5af08e1bafe95f4cb07596ca8f5af184bf5de8f2c4c this is for conda's pyqt. From usage perspective - we currently use the simplified map of name-name but it's possible to have something like spec to spec or spec to array of spec ( if conda package has multiple pypi in it )

Regarding cupy-cuda12x, we map it to cupy right now. Could you please explain me what you would like to see in this case and how you would like to use it?
Thanks

[jaimergp]

Currently we record multiple names and it's versions that are present in source. For example, https://conda-mapping.prefix.dev/hash-v0/4608b9caafc4fa16d887f5af08e1bafe95f4cb07596ca8f5af184bf5de8f2c4c this is for conda's pyqt.

This API is not generally available, right? I don't see this info in any of the files present in this repo.

Regarding cupy-cuda12x, we map it to cupy right now

I don't see cupy-cuda12x in this repo either

Could you please explain me what you would like to see in this case and how you would like to use it?

My point here is that cupy-cuda12x has an implicit constraint on which cuda version gets installed. This doesn't matter over at PyPI because everything's statically linked, but in the dynamic world of conda-forge, we need to specify the runtime libraries too. My current understanding of the CUDA stack in conda-forge is to use cuda-version=12 as the CUDA constraint (see this conda artifact).

The same situation might apply to other wheels with vendored libraries (e.g. BLAS, MPI, etc).

pytorch is a particularly tricky one because the CUDA variants have all the same name, they are just published to different indices (e.g. pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118. Not sure how or even if we could tackle this without some ad-hoc logic like inspecting the wheel URL.

[nichmor]

This API is not generally available, right? I don't see this info in any of the files present in this repo.

It is public available ( and we are using it in pixi ) but all files are stored under our S3. We also are thinking about making more user-friendly API to this ( maybe based on /package_name/version rather than by hash ).

I don't see cupy-cuda12x in this repo either

conda's cupy is present here : https://raw.githubusercontent.com/prefix-dev/parselmouth/main/files/compressed_mapping.json and it maps to cupy. Or you mean something else?

How you would like to see the mapping? More like spec mapping?

{
  name+version : { "pypi_names": [name+version, ...], "virtual_packages": ["cuda"] 
}

[jaimergp]

I'm realizing your mappings are doing conda -> pypi but not the reverse, so maybe what I'm asking doesn't make any sense. But I was thinking of something like:

{
  "cupy-cuda12x": ["cupy", "cuda-version=12"],
  "PyQt5": ["pyqt=5"],
}

[jaimergp]

Coming back to this after reading the updates in conda/grayskull#564, I discovered the API in https://conda-mapping.prefix.dev/pypi-to-conda-v0/conda-forge/pyqt5.json, which is running into the issue I was describing: PyQt5 should map to pyqt=5, not just pyqt.

[tdejager]

The v1 version seems better I think @jaimergp ? https://conda-mapping.prefix.dev/pypi-to-conda-v1/conda-forge/pyqt5.json

[jaimergp]

Ah, so now we can take a (PyPI name, PyPI version) tuple and map it to a conda package name each. Excellent! What happens if a PyPI version was not published in conda-forge? 🤔 null?

Naturally, we assume that the version itself is the same 😂 Why that would be different right...? Let me ruin your day 😬 and let me introduce you to... tzdata! PyPI publishes with 2025.1 and conda-forge with 2025a. :D Fortunately, this is only because PyPI's tzdata is actually python-tzdata in conda-forge. Not sure what conda-forge's tzdata represents.

[tdejager]

🤯🤯🤯

…

On Wed, 11 Feb 2026 at 13:19, jaimergp ***@***.***> wrote: *jaimergp* left a comment (prefix-dev/parselmouth#9) <#9 (comment)> Ah, so now we can take a (PyPI name, PyPI version) tuple and map it to a conda package name each. Excellent! Naturally, we assume that the version itself is the same 😂 Why that would be different right...? Let me ruin your day 😬 and let me introduce you to... tzdata! PyPI publishes with 2025.1 and conda-forge with 2025a. :D — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADF4XTFLLG2DUTG27PI7PL4LMM37AVCNFSM6AAAAABW2HRUDWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQOBUGA3TENRTGM> . You are receiving this because you commented.Message ID: ***@***.***>