In the case of a library that has a dependency that can be met by more than one package, it would be incredibly useful for the library to tell the packaging tools that any of them, if present, is sufficient to meet the install requirements - and if none are present, install a default.
My first idea about this is to extend metadata to allow install_requires to list every package that meets the actual runtime dependencies. While I prefer this option, I can see how this would be a burden on both the PyPA and library maintainers.
My second idea is for
pip install and friends to grow an argument to allow the user to declare that another package+version will substitute in for the one listed in requirements (with the obligatory warning that the software being installed may not be tested in that configuration, if it breaks you get to keep the pieces, etc.)
The real world use case that I have run into is a library that depends on Qt. There are many bindings to Qt with nearly identical APIs, and social or legal reasons to choose one over the other. There are also abstraction layer libraries that pave over the few differences between versions of Qt bindings (and in some cases major versions of Qt itself). The problem lies in the case where the library needs to choose a binding to Qt for install_requires so their library will work, but cannot tell pip that any bindings to Qt will work just fine.