Additional constraints / matching package with different names in different repo/channels

[rjanvier]

Hi there👋,
I have an issue with Pixi, maybe there is a trivial solution that I have overlooked but maybe it could be a feature for Pixi.

If I understand well, if I install a pypi package in my project (via the [pypi-dependencies] section) any dependency of this package that have a conda equivalent (name and compatible version) already installed in the project won't be fetched from uv pip. Given that, my issue is with "equivalent" package in both "world" (conda channels and pipy) that don't share the same name. For example the python package I try to integrate in my Pixi project depends on PyQt5 which simply called pyqt on conda-forge. As a result, even if I already have declared pyqt as a dependency in my Pixi project, Pixi tries to download, build and install PyQt5 from PyPi. Have you any advices on how can I deal with such cases? Else it would be nice to add a way to I declare additional constraints (equivalence of package in multiple repositories/channels or even blacklist of package in a given repository/channel) to dependencies in Pixi.

[rjanvier]

ok, sorry stupid question, it seems it exists a conda-pypi mapping that maps both "world" but is seems to be buggy (?) in my case.
I run on macOS arm64 (apple silicon) on macOS 14. step to reproduce:

pixi init debug
cd debug
pixi add pyqt
pixi add pyqt5 --pypi

the process get stuck (I think it is trying to build pyqt5 from source)

now if I change env from osx-arm64 to osx-x64, all is working fine.

[ruben-arts]

Our map includes: "pyqt": "pyqt5" thus I'm assuming it should not build pyqt5 again. But I'm able to reproduce your example. So I guess you found a bug.

For my fellow devs:

[project]
name = "debug"
channels = ["conda-forge"]
platforms = ["osx-arm64"]

[dependencies]
pyqt = ">=5.15.9,<5.16"

[pypi-dependencies]
pyqt5 = "*"

pixi install -vvv

The conda resolve tells the resolve pypi that it has pyqt5 already.

 INFO resolve_pypi{group=default platform=osx-arm64}: pixi::lock_file::resolve: the following python packages are assumed to be installed by conda: ... pyqt 5.15.9, pyqt5-sip 12.12.2, ...

But uv start solving for the these packages, and then also seems to get stuck for some reason. This is the only thing I could make sense of from the log:

DEBUG resolve_pypi{group=default platform=osx-arm64}:get_or_build_wheel_metadata{dist=pyqt5==5.15.9}:build_distribution{dist=pyqt5==5.15.9}:setup_build{version_id="pyqt5==5.15.9" subdirectory=None}: uv_build: Calling `sipbuild.api.get_requires_for_build_wheel()`
DEBUG resolve_pypi{group=default platform=osx-arm64}:get_or_build_wheel_metadata{dist=pyqt5==5.15.9}:build_distribution{dist=pyqt5==5.15.9}:build_wheel{version_id="pyqt5==5.15.9"}: uv_build: Calling `sipbuild.api.build_wheel(metadata_directory=None)`

[nichmor]

hey @rjanvier ! Thank you for reporting this.

Indeed this is a problem for pyqt on osx-arm64 as it don't have a .dist-info inside conda package and we don't treat it as pypi. This is not a case for linux-64 or osx-64 - that's why you don't have this problem for these platforms.

I'm still unaware of "why" there are difference between them so I will try to find an answer and will let you know.

[ruben-arts]

For reference the same issue occurs for linux-aarch64: https://conda-mapping.prefix.dev/hash-v0/e2d067fa38c905e2fb2ee80951ad907128e797c3f29dc325a1e27506bfff7c0f

[rjanvier]

Hi, thank you very much for your quick and kind replies. I was not sure it was a bug since I'm not yet very experienced in conda ecosystem.
If there is anything I can do to help making this work, please let me know!

[rjanvier]

Hi, I tested today and it seems to be solved, thanks! For the sake of curiosity, have you any idea on what was the issue?