The desupport did in fact include appropriate
Requires-Python metadata, and so should in theory have been seamless for users. However, it looks as if in practice,
Requires-Python (and more specifically the
data-requires-python tag for index servers) isn’t always exposed on custom indexes, and that’s what caused the worst problems.
So I think that the lessons here should be:
data-requires-python) isn’t as robust a transition mechanism as we’d like.
- Core PyPA tools (like pip, setuptools and virtualenv) are used heavily in automated setups that pick up the latest release without warning and without in-advance testing. We can bemoan that as bad practice as much as we want, but it’s a reality that we need to deal with.
While projects should remain able to decide for themselves how they handle Python 2 desupport, it’s not unreasonable to expect sufficient advance warning, at least so that the various PyPA tools can provide a co-ordinated approach. We’ve had a number of “new release broke X” issues recently, and while they mostly haven’t been things we can control (see the points above) we should do what we can to be more prepared.