Mechanism for multiple packages to provide the same virtual package #8669
Labels
resolution: needs standard
Should be agreed as a standard before implementation
state: needs discussion
This needs some more discussion
type: enhancement
Improvements to functionality
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
The text was updated successfully, but these errors were encountered: