Incorrect requires-python version on /simple/ if Python version was changed during the release

[Andrej730]

Hi, we've run into a problem posting a release on PyPi - we posted in two parts:

• 3.9-3.12
• 3.13, the same release but we've changed 'requires-python' from ">=3.9,<3.13" to "">=3.9,<3.14"".

But now a problem occurred, when user is trying to install pip install ifcopenshell on Python 3.13 they get:

ERROR: Ignored the following versions that require a different python version: 0.7.0.240406 Requires-Python <3.13,>=3.9; 0.7.0.240418 Requires-Python <3.13,>=3.9; 0.7.0.240423 Requires-Python <3.13,>=3.9; 0.7.0.240518 Requires-Python <3.13,>=3.9; 0.7.0.240521 Requires-Python <3.13,>=3.9; 0.7.0.240627 Requires-Python <3.13,>=3.9; 0.7.0.250519 Requires-Python <3.13,>=3.9; 0.7.10 Requires-Python <3.13,>=3.9; 0.8.0 Requires-Python <3.13,>=3.9; 0.8.1 Requires-Python <3.13,>=3.9; 0.8.1.post1 Requires-Python <3.13,>=3.9; 0.8.2 Requires-Python <3.13,>=3.9; 0.8.3 Requires-Python <3.13,>=3.9; 0.8.3.post1 Requires-Python <3.13,>=3.9

I've investigated pip code and I believe the page it's relying on for identifying python versions is https://pypi.org/simple/ifcopenshell/

And there's a bit of a problem with this page - it still lists >=3.9,<3.13, even for Python 3.13 package.

<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7" data-core-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7">ifcopenshell-0.8.3.post1-py311-none-win_amd64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7" data-core-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7">ifcopenshell-0.8.3.post1-py312-none-macosx_10_15_x86_64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7" data-core-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7">ifcopenshell-0.8.3.post1-py312-none-macosx_11_0_arm64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7" data-core-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7">ifcopenshell-0.8.3.post1-py312-none-manylinux_2_31_x86_64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7" data-core-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7">ifcopenshell-0.8.3.post1-py312-none-win_amd64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=2116f9dd9d7aa4f92e50016a191e3a41a4f14ed77053a707aee21f4890b0f60b" data-core-metadata="sha256=2116f9dd9d7aa4f92e50016a191e3a41a4f14ed77053a707aee21f4890b0f60b">ifcopenshell-0.8.3.post1-py313-none-macosx_10_15_x86_64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=2116f9dd9d7aa4f92e50016a191e3a41a4f14ed77053a707aee21f4890b0f60b" data-core-metadata="sha256=2116f9dd9d7aa4f92e50016a191e3a41a4f14ed77053a707aee21f4890b0f60b">ifcopenshell-0.8.3.post1-py313-none-macosx_11_0_arm64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=2116f9dd9d7aa4f92e50016a191e3a41a4f14ed77053a707aee21f4890b0f60b" data-core-metadata="sha256=2116f9dd9d7aa4f92e50016a191e3a41a4f14ed77053a707aee21f4890b0f60b">ifcopenshell-0.8.3.post1-py313-none-manylinux_2_31_x86_64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=2116f9dd9d7aa4f92e50016a191e3a41a4f14ed77053a707aee21f4890b0f60b" data-core-metadata="sha256=2116f9dd9d7aa4f92e50016a191e3a41a4f14ed77053a707aee21f4890b0f60b">ifcopenshell-0.8.3.post1-py313-none-win_amd64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7" data-core-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7">ifcopenshell-0.8.3.post1-py39-none-macosx_10_15_x86_64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7" data-core-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7">ifcopenshell-0.8.3.post1-py39-none-macosx_11_0_arm64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7" data-core-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7">ifcopenshell-0.8.3.post1-py39-none-manylinux_2_31_x86_64.whl</a><br />
<a href="" data-requires-python="&lt;3.13,&gt;=3.9" data-dist-info-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7" data-core-metadata="sha256=44c5222276f7decb7006a049bc7f79f2a354752f46a12180a703f2461ed497e7">ifcopenshell-0.8.3.post1-py39-none-win_amd64.whl</a><br />

E.g. if you download one of the 3.13 wheels -
https://files.pythonhosted.org/packages/79/1b/d1f1c9da1ff4c6f4a39eb720d31c1dab82937afe710441cac7a34d61a29d/ifcopenshell-0.8.3.post1-py313-none-manylinux_2_31_x86_64.whl#sha256=a32e8f13e1c7d34d539e91d293378028224e707bbc7274a045938cc3eb1c66fd

It has Requires-Python: <3.14,>=3.9 in it's "METADATA".

[di]

It looks like we've recorded the wrong requires_python value for these files:

warehouse=> select requires_python from release_files where filename = 'ifcopenshell-0.8.3.post1-py313-none-manylinux_2_31_x86_64.whl';
 requires_python
-----------------
 <3.13,>=3.9
(1 row)

However this metadata ultimately comes from the form details provided at upload time, and not from the metadata within the artifact:

warehouse/warehouse/forklift/legacy.py

Lines 620 to 624 in fd5b2de

	# Get a validated Metadata object from the form data.
	# TODO: We should eventually extract this data out of the artifact and use that,
	# but for now we'll continue to use the form data.
	try:
	meta = metadata.parse(None, form_data=request.POST)

It's currently the responsibility of the upload client to parse this metadata from the file and provide it to PyPI at upload time alongside the file.

Can you give us more details about how you published these files?

[Andrej730]

Can you give us more details about how you published these files?

Sure, it was through Github Workflow, we have the logs:

• 3.9-3.12 builds - https://github.com/IfcOpenShell/IfcOpenShell/actions/runs/16319425304
• 3.13 builds - https://github.com/IfcOpenShell/IfcOpenShell/actions/runs/16443693982

[di]

Can I ask why you're using https://github.com/ortega2247/pypi-upload-action instead of https://github.com/pypa/gh-action-pypi-publish? It seems like that project has not been updated in the last ~5 years.

[Andrej730]

Can I ask why you're using ortega2247/pypi-upload-action instead of pypa/gh-action-pypi-publish? It seems like that project has not been updated in the last ~5 years.

Got the same question reading through the logs just now 😅
I believe there's no particular reason, it just seemed to work fine and we've never updated it. We'll switch to https://github.com/pypa/gh-action-pypi-publish

But under the hood it seems to use just twine command /opt/hostedtoolcache/Python/3.11.13/x64/bin/python -m twine upload -u __token__ -p *** --repository-url src/ifcopenshell_win64_py313/dist/*. Given that it's still using the latest version of twine and, it shouldn't be a problem (unless there's a bug in twine)?

[di]

I haven't looked closely at this workflow but since we haven't gotten any similar reports, I think it's likely it's the culprit. Can you using the PyPA workflow instead and see if the issue persists?

[Andrej730]

Haven't tested PyPA workflow, but I was able to reproduce the issue with just twine locally.

I've uploaded two wheels to https://test.pypi.org/project/test-pypi-req/0.1.0/#files - 3.9 was uploaded first (with <3.13 metadata), 3.13 (with <3.14 metadata) was uploaded second.

test_pypi_req-0.1.0-py39-none-win_amd64.whl.txt
test_pypi_req-0.1.0-py313-none-win_amd64.whl.txt

And on https://test.pypi.org/simple/test-pypi-req/ they both have "<3.13" required Python.

Not familar with twine codebase, but stepping a bit through upload process with a debugger, it seems data_to_send that has 'requires_python' before it's encoded and sent to PyPI has the correct data. So it's possible that it's not a client issue?

https://github.com/pypa/twine/blob/c1c02d13d00f496339a86cd4f40d9f7e6926c0e4/twine/repository.py#L126

00 = ('summary', 'A test package for TestPyPI with fake Windows-specific wheel')
01 = ('author', 'Andrej')
02 = ('version', '0.1.0')
03 = ('name', 'test-pypi-req')
04 = ('metadata_version', '2.4')
05 = ('requires_python', '<3.14,>=3.8')
06 = ('description_content_type', 'text/markdown')
07 = ('pyversion', 'py313')
08 = ('filetype', 'bdist_wheel')
09 = ('sha256_digest', '15f75c24477d6a81bf3833846c07159675e5d71da742be306f52020fa1785287')
10 = ('md5_digest', 'b1d69bf9cd0ade623e049ce5ad553476')
11 = ('blake2_256_digest', '2192db5b1bddc2ffbe80e879331730b4f49b802f2c07c2b61adeded3c013427b')
12 = (':action', 'file_upload')
13 = ('protocol_version', '1')
14 = ('content', ('test_pypi_req-0.1.0-py313-none-win_amd64.whl', <_io.BufferedReader name='dist\\test_pypi_req-0.1.0-py313-none-win_amd64.whl'>, 'application/octet-stream'))

[di]

Ah, you're right, I should have realized this is #8090, marking this as blocked on that issue.

[Andrej730]

Is there any way to update per-release metadata to bump allowed Python version or it's recorded when the first file from the release is uploaded and that's it?

[di]

It's not possible to modify metadata after the file has been published. Indeed, it's recorded from the first file, the best workaround right now is to make separate releases.