On my phone so excuse my brevity.
My general opinion is that the packaging toolchain needs to be conservative in dropping support for packaging and installing packages on Python 2 and use a usage based methodology for deciding when to drop support for that.
To unpack that statement first let’s look at the why.
The main underlying reason is that I think it will hamstring our ability to continue to improve Python’s packaging. Obviously someone has to upgrade the versions of the relevant tools in order to get support for new features. However if a project is supporting 2.7 for one reason or another then they are going to be stuck using only the features that existed in the 2019 era toolchain unless we go to great lengths to make sure that all new standards degrade gracefully. This is similar to what happened in the Python itself with the Python 3 introduction where for most users of Python, new improvements basically didn’t exist. I feel like it’s widely regarded that splitting the user base like that was a mistake (at least in terms of strategy) and I feel that we’d essentislly be doing the same thing.
Now, I worded that statement to focus on the ability to continue to support Python 2 projects for installation and packaging but only that. So for instance I think that it is fine to only support running a particular project under Python 3 as long as they can still package/install a Python 2 project.
For projects like bandersnatch (and PyPI) that requirement is easy to satisfy because we’re treating the files as largely opaque blobs. For projects that need to more directly interact with the packages themself (either producing them or consuming them) it is a lot trickier. Generally I think that until usage numbers go down, those projects need to do one of two things. Either they can continue to support Python 2 wholly OR they can add a (or utilize an existing) feature that allows them to target an environment other than the one they’re being run under. So example I think it’s fine for tox to only support running itself under Python 3 as long as a Python 2 environment is still reasonably possible.
There’s also the question of what it means to “support” Python 2. Generally I would say that it means that we continue to keep CI for Python 2 and ensure that the tool generally works on Python 2 (including new features). However I don’t think that it means that we, as maintainers, need to focus on Python 2 only bugs.
I’m struggling to come up with a proper term for it, but generally I’m thinking of a sort of life support where we keep the lights on but not much else. I think as part of that it would be fine to start raising warnings with some links and description of this kind of life support support. I even think it would be fine to say that any bug that gets reported that can’t be reproduced under Python 3 either gets closed or tagged for “community support” basically saying PRs fixing it would be accepted, but the project itself isn’t going to be looking at it.
Largely though, I don’t think we should pick hard dates right now. I think fracturing our user base is going to make things harder, not easier for us as a whole. However I think we can start taking steps to reduce that amount of Python 2 support work that we need to do.