this has caused a fairly large problem for downstream users, due to the need to upgrade setup tools for this inconsequential change, which has caused some downstream dependencies to freeze, resulting in a large amount of churn for thousands of downstream packages and developers as their forced to pin to 2.8.0. a large portion of that is due to boto3's own issues with its installers, but packaging decisions that cause deprecation of extant releases really need careful consideration in libraries. given this is effectively a non functional change, is there any interest in a pr that would revert it, its unclear what value the change was delivering, especially measured by its negative impact to users.

@kapilt No thank you. dateutil ships a universal wheel, so it shouldn't really matter what version of setuptools you have, and if you insist on building dateutil from scratch, you should use a recent version.

If for some reason you need to build dateutil from source (which should be rare), the version of setuiptools required to build dateutil is documented in the pyproject.toml, and the current version of dateutil is intended to be built with a PEP 517-compatible front-end. Deviations from this are basically unsupported configurations.

I would also note that it is dangerous to use an old version of setuptools, as you are likely to generate bad metadata, or cause problems with your install environment.