Here is a PR which reverts this: https://github.com/pypa/setuptools/pull/4911
Interesting that maintainers of setuptools still only postpone the depreciation date for a year, so we can probably expect more issues like this in the future.
Took them seemingly forever to do. The reversion, sure, that might take a bit to proof, but the yank should have been done way sooner
afaict they just released 78.0.2 with a revert of the offending bits
This is one of those situations where the scale of the software package is so large that even if only 0.1% of users had issue, that's a number representing tens of thousands of people.
In the rationale for this that I can find [1], a maintainer says the following:
> I'm inclined to say we should do it, even though it will cause some disruption.
They also say an alternative is to "accept the status quo", which is exactily what they should be doing. I can't find maintainers giving a compelling reason not to support this status quo of `long-description` as an alias to `long_description` besides "simplifying code." Code simplification should never take precedence over massive breakage of compatibility.
[1] https://github.com/pypa/setuptools/pull/4870#pullrequestrevi...
> The maintainers of setuptools get paid by Tidelift to
> implement industry-leading secure software development
> practices and document the practices they follow.
Well, that really doesn't seem so in this case now, does it?
The conditions that lead to having two tokens pointing to the same functionality should be prevented, but in this case it is a "de facto" alias which no amount reasonable amount of labor could fix.
