The deep --exclude work in #2409 opens the door to easily supporting re-writing the 3rdparty requirements Pip sees during the resolve process. This would allow loosening a 3rdparty requirement range or even completely swapping one dependency for another.
I am aware of cases where folks have wanted to loosen / expand a 3rdparty requirement to allow an impossible resolve to succeed where they know the altered requirement is valid for their use case.
I am not aware of cases where completely swapping a dependency out was needed, but you could imagine using this to publish a private wheel with a project name that bears no relation to the packaged code, which is code of some 3rdparty project with fixes. Although you could usually use a VCS requirement for this sort of 3rdparty patching, VCS requirements are sdists and require wheel builds on the fly, which can be sub-optimal.
The deep
--exclude
work in #2409 opens the door to easily supporting re-writing the 3rdparty requirements Pip sees during the resolve process. This would allow loosening a 3rdparty requirement range or even completely swapping one dependency for another.I am aware of cases where folks have wanted to loosen / expand a 3rdparty requirement to allow an impossible resolve to succeed where they know the altered requirement is valid for their use case.
I am not aware of cases where completely swapping a dependency out was needed, but you could imagine using this to publish a private wheel with a project name that bears no relation to the packaged code, which is code of some 3rdparty project with fixes. Although you could usually use a VCS requirement for this sort of 3rdparty patching, VCS requirements are sdists and require wheel builds on the fly, which can be sub-optimal.