Hotfix for requests 2.32.2

[krissetto]

Carried from #3257 to try and avoid strange CI caching issues

[thaJeztah]

Same error; wonder if some dependency started to become more strict, or if we need to rewrite the commit to be semver(ish) (perhaps some git describe -tags); it's possible that if it does a shallow clone of git, that it doesn't have tags, so git describe would not base version on any tags 🤔

#21 4.019   × Preparing metadata (pyproject.toml) did not run successfully.
#21 4.019   │ exit code: 1
#21 4.019   ╰─> [23 lines of output]
#21 4.019       Traceback (most recent call last):
#21 4.019         File "/usr/local/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
#21 4.019           main()
#21 4.019         File "/usr/local/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
#21 4.019           json_out['return_val'] = hook(**hook_input['kwargs'])
#21 4.019                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#21 4.019         File "/usr/local/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 152, in prepare_metadata_for_build_wheel
#21 4.019           whl_basename = backend.build_wheel(metadata_directory, config_settings)
#21 4.019                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#21 4.019         File "/tmp/pip-build-env-6l566k50/overlay/lib/python3.12/site-packages/hatchling/build.py", line 58, in build_wheel
#21 4.019           return os.path.basename(next(builder.build(directory=wheel_directory, versions=['standard'])))
#21 4.019                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#21 4.019         File "/tmp/pip-build-env-6l566k50/overlay/lib/python3.12/site-packages/hatchling/builders/plugin/interface.py", line 90, in build
#21 4.019           self.metadata.validate_fields()
#21 4.019         File "/tmp/pip-build-env-6l566k50/overlay/lib/python3.12/site-packages/hatchling/metadata/core.py", line 265, in validate_fields
#21 4.019           _ = self.version
#21 4.019               ^^^^^^^^^^^^
#21 4.019         File "/tmp/pip-build-env-6l566k50/overlay/lib/python3.12/site-packages/hatchling/metadata/core.py", line 149, in version
#21 4.019           self._version = self._get_version()
#21 4.019                           ^^^^^^^^^^^^^^^^^^^
#21 4.019         File "/tmp/pip-build-env-6l566k50/overlay/lib/python3.12/site-packages/hatchling/metadata/core.py", line 260, in _get_version
#21 4.019           raise ValueError(message) from None
#21 4.019       ValueError: Invalid version `55f1c00` from source `vcs`, see https://peps.python.org/pep-0440/
#21 4.019       [end of output]

Als no idea where 55f1c00 comes from, as that's not the commit in this PR; is it possible something does a "merge" before running CI? 🤔

[thaJeztah]

Ah, yes, looks like; 55f1c00

Says "Merge bf89113 into b6464db"

[thaJeztah]

[thaJeztah]

Right, so So commit 9ad4bdd changed the Makefile to generate a version based on git describe --tags;

docker-py/Makefile

Lines 14 to 17 in b6464db

	SETUPTOOLS_SCM_PRETEND_VERSION_DOCKER ?= $(shell git describe --match '[0-9]*' --dirty='.m' --always --tags 2>/dev/null | sed -r 's/-([0-9]+)/.dev\1/' | sed 's/-/+/')
	ifeq ($(SETUPTOOLS_SCM_PRETEND_VERSION_DOCKER),)
	SETUPTOOLS_SCM_PRETEND_VERSION_DOCKER = "dev"
	endif

On a local checkout of this repository, I get a valid semver(ish) output;

git describe --match '[0-9]*' --dirty='.m' --always --tags
7.0.0-27-gb6464dbe

git describe --match '[0-9]*' --dirty='.m' --always --tags 2>/dev/null | sed -r 's/-([0-9]+)/.dev\1/' | sed 's/-/+/'
7.0.0.dev27+gb6464dbe

However, GitHub "checkout action" does a shallow clone / doesn't do a full fetch;

mkdir foo && cd foo
git init

git remote add origin https://github.com/docker/docker-py

git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=1 origin +55f1c003017f27fe0c0896acbf066a929c8d5653:refs/remotes/pull/3259/merge

git sparse-checkout disable
git config --local --unset-all extensions.worktreeConfig
git checkout --progress --force refs/remotes/pull/3259/merge
git log -1 --format='%H'
# 55f1c003017f27fe0c0896acbf066a929c8d5653

And in that case, the result is just the commit-sha, no tags involved, so nothing semver(ish); it even fails;

git describe --match '[0-9]*' --dirty='.m' --always --tags
55f1c00

git describe --match '[0-9]*' --dirty='.m' --always --tags 2>/dev/null | sed -r 's/-([0-9]+)/.dev\1/' | sed 's/-/+/'
55f1c00

[thaJeztah]

Oh! Last PR merged was the one that made the change! So that one never ran with the changes!

• chore(ci): fix-ups across Make / Docker / GitHub Actions #3241

[thaJeztah]

Hmm.. no that's not it; that PR also had a "commit-only" version; https://github.com/docker/docker-py/actions/runs/8485006285/job/23304280050

[thaJeztah]

Hm... so the fetch-tags option in checkout action does remove the --no-tags, but I think it still fails because it fetches from the PR branch / fork, so may not get tags still.

Before that PR above, the Dockerfile would use 99.0.0+docker as default. I wonder what the PR was fixing (perhaps caching?), and wondering if we should change the Makefile to NOT take tags into account, and just use 99.0.0+<git-sha>, so always use 99.0.0+ as prefix, followed by git-commit.

That would still make it a "unique" tag (prevent caching?) and make it a "valid" format?