v3.1.0 fails on python < 3.11

[TLCFEM]

See https://github.com/TLCFEM/suanPan/actions/runs/18810757760/job/53671556817

 Collecting urllib3==2.5.0
  Downloading urllib3-2.5.0-py3-none-any.whl (129 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 129.8/129.8 KB 49.6 MB/s eta 0:00:00
Collecting importlib_resources~=5.7
ERROR: In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
    importlib_resources~=5.7 from https://files.pythonhosted.org/packages/7a/68/bd9dd6bbf06772c7accce77d0354d783333fbe712a60b08fc13540c05422/importlib_resources-5.13.0-py3-none-any.whl#sha256=9f7bd0c97b79972a6cce36a366356d16d5e13b09679c11a58f1014bfdf8e64b2 (from sigstore==4.1.0->-r /home/runner/work/_actions/sigstore/gh-action-sigstore-python/v3.1.0/requirements/main.txt (line 481))

[woodruffw]

Thanks for the report.

I'm confused by where importlib_resources~=5.7 is coming from: we don't have it anywhere in our pinned dependencies on 3.1.0:

https://github.com/sigstore/gh-action-sigstore-python/blob/f832326173235dcb00dd5d92cd3f353de3188e6c/requirements/main.txt

[TLCFEM]

It comes from your upstream.

https://github.com/sigstore/sigstore-python/blob/a62ef97ae3e45e2589fdb372f65c89cf55fdcd6b/pyproject.toml#L32

[TLCFEM]

I think the following can be done to improve this repo.

1. A more thorough job matrix, currently it uses 3.x, which is the latest stable only.
   

   gh-action-sigstore-python/.github/workflows/selftest.yml

   Line 20 in 27dac9c

   python-version: ["3.x", "3.14"]

   
   https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#specifying-a-pypy-version
2. Apart from the patch tag v3.1.0, minor version tag and major version tag v3.1 and v3 may also be added. By such downstreams do not have to manually bump up version when v3.0.1 fails.

[woodruffw]

It comes from your upstream.

sigstore/sigstore-python@a62ef97/pyproject.toml#L32

Right, but we shouldn't actually hit that here, since the dependencies are fully pinned.

(This might have been a misunderstanding on my part -- I thought that hash-pinning implied --no-deps in pip, but it seems like it doesn't.)

1. A more thorough job matrix, currently it uses 3.x, which is the latest stable only.

Yeah, we should definitely do this. However, based on #235 we're probably going to increase our minimum Python to 3.10+, since we're intentionally locking on dependencies that need that version.

2. Apart from the patch tag v3.1.0, minor version tag and major version tag v3.1 and v3 may also be added. By such downstreams do not have to manually bump up version when v3.0.1 fails.

FWIW, there's a reason we don't do this: it would require us to force-push tags on every release, and tag mutability makes a lot of downstream consumption lot harder to enforce (since users would need to deal with us rewriting tags on them).

My recommendation for these kinds of bumps would be to use Dependabot or Renovate -- both can automate the bumping process for you.

[woodruffw]

This looks related: pypa/pip#9644

[jku]

I thought that hash-pinning implied --no-deps in pip, but it seems like it doesn't.

It does imply that, this is why this failure happens, right? IF we wanted to support all python versions we'd basically have to run pip-compile for every supported python version separately to produce correct requirements lists...

based on #235 we're probably going to increase our minimum Python to 3.10+, since we're intentionally locking on dependencies that need that version.

yeah I think that's the right call for an action, doing a lot of work to support multiple versions does not seem like a good use of resources. That said, maybe we should go straight to 3.11 to "fix" this issue as well (since the importlib dependency is for python_version < '3.11'

Now testing multiple versions does seem useful: we definitely should be doing that

[jku]

maybe we should go straight to 3.11 to "fix" this issue as well (since the importlib dependency is for python_version < '3.11'

the alternative would be to produce separate requirements.txt files for all supported python versions... But that of course will not work with dependabot as we can't affect the python version it uses: We'd have to start running pip-compile in CI ourselves and all that fun

[woodruffw]

Yeah, I would definitely be pro- going 3.11+ and enforcing the Python version at runtime through uv or setup-python, rather than using whatever the runner has.