Upgrade setuptools-scm

[jessicamack]

Upgrading setuptools-scm to work with the upgrading of the package in AWX

[nitzmahone]

I think we just capped the build dep versions for safety after the PyYAML Cython fiasco and knowing setuptools is going to start breaking things more aggressively too. If we're going to do a new release just to bump setuptools_scm, might as well bump setuptools up to the latest too.

Bigger picture question though: why isn't AWX vendoring a wheel instead of a source tarball? Then you don't have to care- either ship the wheel we provide on PyPI or roll your own during the AWX release process (which would run in an isolated build like it's supposed to and "just work").

[shanemcd]

Bigger picture question though: why isn't AWX vendoring a wheel instead of a source tarball?

IIRC this is due to needing to vendor the source inside of our source RPM. But honestly ... the answer to this question shouldn't matter right? You also hit this error if you're simply trying to install from git with newer versions of setuptools / setuptools-scm. IMHO it's bad practice to cap these kinds of deps unless they are causing some issue.

[AlanCoding]

@jessicamack could you give more information about why this is needed? What upgrade error led you down this path?

[AlanCoding]

Link the code conflict:

https://github.com/ansible/django-ansible-base/blob/486c4d003c2982f4e817fd7cff7afa3b455554a0/pyproject.toml#L36

setuptools_scm>=8

Since these are both public projects that makes this fairly clear. Either runner changes or ansible_base changes to be compatible.

@john-westcott-iv any preference?

[shanemcd]

I have a preference ... if there is no real reason why runner pins this, why make other projects cargo-cult this tech debt?

[AlanCoding]

I agree with that preference, I just want to frame what the conflict is and establish why this is a priority now.

[sivel]

You also hit this error if you're simply trying to install from git with newer versions of setuptools / setuptools-scm

Generally speaking, you would be building in an isolated environment. pip by default does this, although the downstream RPM packaging runs with --no-build-isolation but is only building a single package at a time.

I'm not sure in what manner of building/installing would cause this issue. Answering the question of "What upgrade error led you down this path?" would be good to know. Since any source should be turned into a wheel intermediately, I'm not sure where this happens. I tested a pip install of both of these packages, with no errors. Unless for some reason they are all being pip installed simultaneously with also specifying --no-build-isolation.

Regardless of this being 2 packages "we" own, this could happen for any other number of packages. It seems like there are some assumptions that are not true, that are at a level above this problem, that we might want to address.

[Shrews]

Tested this change and the only difference in metadata (between these versions and the current versions from devel) that I can see is that the source distro's PKG-INFO file contains these additional lines:

Requires-Dist: pexpect>=4.5
Requires-Dist: packaging
Requires-Dist: python-daemon
Requires-Dist: pyyaml
Requires-Dist: importlib-metadata<6.3,>=4.6; python_version < "3.10"

Those lines appear in both versions of the .whl package's METADATA file.