Unblock setuptools_scm

[alerque]

This should un-bork what #1346 broke for folks that are actually in current instead of EOL Python envirenments.

[pganssle]

Unfortunately this doesn't work, because the issue is that we build the tarball and the wheel once, using some arbitrary Python version, targeting all Python versions.

If we wanted to continue using setuptools_scm while we're still supporting old Python versions, the right way to do it would be to detect the setuptools_scm version in setup.py and set a version_file_template in versions of setuptools_scm that support that (I believe write_to would also need to be changed to version_file in that case).

Unfortunately (and ironically), setuptools_scm doesn't expose a __version__ attribute, and we can't pull in any dependencies on importlib.metadata or its backports.

Instead, for future releases I plan to remove setuptools_scm entirely (see #1347), and for now we can pin to a version that does what we're expecting.

[tucked]

Couldn't we use importlib_metadata instead of the version template?
Or better yet.... drop support for EOL pythons (downstreams can continue using the older versions)?

[alerque]

Unfortunately this doesn't work, because the issue is that we build the tarball and the wheel once, using some arbitrary Python version, targeting all Python versions.

If the issue is what ends up in the wheel, then setup your wheel builder to use the version you want to use, don't block everybody else from building with current tooling. The solution in this PR should work for the source dist tarball for anybody building it.

Instead, for future releases I plan to remove setuptools_scm entirely (see #1347), and for now we can pin to a version that does what we're expecting.

That's up to you. In general using vcs/scm versioning modules is a good thing for distros because it allows them to build devel packages from Git HEAD with sensible version data. It also usually gives an extra channel that works for builds (being able to use Git archive sources instead of source dist tarballs while still getting the expected version info). I package hundreds of Python libraries for Arch and usually having setuptools_scm (or equivalent for other Python build systems) is usually just fine. I don't think you necessary need to give up on those advantages.

[pganssle]

If you would like to build and deploy something different from the standard version of dateutil that is your decision, but for now the official version does not include type hints in _version.py, and I'm not interested in introducing differences in the output depending on what version of Python is used to generate releases, which is what this PR does.

Thank you for your contribution.

[tucked]

building with current tooling.

If you build this PR with current tooling, you end up with a package that claims to support py2 but doesn't support py2.

[alerque]

I'm not trying to "deploy" or "generate releases". I'm trying to build and install against system-provided dependencies. In other words anybody not operating on a per-project silo basis such as venvs or whatever is going to have trouble with this not being addressed.

I'm not asserting this PR is the correct fix, I'm just asserting that there is an issue with different scope than what the pushback to this PR seems to be assuming.