Mechanism for multiple packages to provide the same virtual package
Opened this issue · 2 comments
What's the problem this feature will solve?
Currently some libraries have multiple packages on PyPI to fulfill different use cases. For example:
psycopg2 vs psycopg2-binary: These packages provide psycopg2 without and with a wheel package, due to problems the maintainers have had with wheel packages. The two packages logically provide the same library but only the latter will install a wheel. The problem relates to linking with compatible versions of libssl. See: psycopg/psycopg2#674
opencv-python-headless vs opencv-python: The latter has GUI functionality whereas the former doesn't.
There are probably others e.g. "foo" and "foo-gpu" may exist for some packages. Please go ahead and comment with more examples.
Describe the solution you'd like
Multiple packages would be able to "provide" the same resource, specified e.g. in the pyproject.toml.
Any downstream package could then decide on which concrete package they wanted to provide the virtual package. There could be some way of choosing a default.
Additional context
This functionality could become more important when dependency resolution becomes more strict. See also: #8076
Other package management systems have this mechanism. See e.g. https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides
Would you mind opening a thread on discuss.python.org? This requires multiple things in the packaging ecosystem to work, and pip is arguably one of the last. And a PEP would be required, if I’m not mistaken. Some of the people on there may be able to offer more thoughts about this.
Agreed, this would need discussion. I believe it's also been discussed previously, so you might want to research the history (a good thing to search for is probably the Provides-Dist metadata item) as well.