Closed Abacn closed 1 month ago
cc: @jaraco
Thanks for the report and sorry for the inconvenience.
I think this is another case of "working as intended", based on PEP 625. Curiously, I can't find in the spec where it's indicated that trailing zeros are stripped, but that's the way the normalization is implemented.
See #4300 where the same rationale applies.
The setuptools 69.4.0
release sdist tarball is affected too. The tarball is named setuptools-69.4.0.tar.gz
while the directory with the sources inside is setuptools-69.4
. It would be great if both versions match.
See #3593 for the rationale behind this change. I do agree that it seems strange that the sdist filename doesn't match the internal name. That sounds like a bug. I'll follow up in that issue.
Given bugs in the normalization logic, I would consider reverting these changes or yanking the release, until the bugs are addressed; otherwise we might have to pin to an older version of setuptools until fixes are available.
Yes, that seems sensible. I've yanked the 69.3 and 69.4 releases.
The
setuptools 69.4.0
release sdist tarball is affected too. The tarball is namedsetuptools-69.4.0.tar.gz
while the directory with the sources inside issetuptools-69.4
. It would be great if both versions match.
That's not what I'm seeing:
draft @ pip download --no-binary setuptools setuptools==69.4.0 -q
WARNING: The candidate selected for download or install is a yanked version: 'setuptools' candidate (version 69.4 at https://files.pythonhosted.org/packages/7a/12/dc02a2401dac87cb2d3ea8d3b23eab30db4cd2948d5b048bf912b9fe959a/setuptools-69.4.tar.gz (from https://pypi.org/simple/setuptools/) (requires-python:>=3.8))
Reason for being yanked: https://github.com/pypa/setuptools/issues/4302
draft @ ls *.tar.gz
setuptools-69.4.tar.gz
The version in the tarball matches the new, preferred, canonical version (as returned by packaging.utils.canonical_version
).
It's true that the version of the tarball in GitHub is going to be different, but that's because the version is going to match the tags or release, which are out of scope for the PEP. Because the PEP specifies one thing but semver specifies another, it's not going to be possible for a project to keep them in sync.
I'm releasing v69.3.1 and v69.4.1 with hotfixes for this issue. Version numbers will once again retain trailing zeros.
The
setuptools 69.4.0
release sdist tarball is affected too. The tarball is namedsetuptools-69.4.0.tar.gz
while the directory with the sources inside issetuptools-69.4
. It would be great if both versions match.That's not what I'm seeing:
You are right, the sdist tarball for 69.4(.0) is named properly. I'm sorry, I've got confused by the PyPI version which is 69.4.0 and this does not match the sdist.
setuptools version
69.3.0 and above
Python version
Python 3.8
OS
Linux / macOS / windows
Additional environment information
No response
Description
Found in https://github.com/apache/beam/issues/30955,
setuptools trim the version number of ".0" when tarball gets built
If the package version is
1.0.0
, now, it trimmed to1
.If the package version is
1.0.0.dev0
, now, it trimmed to1.dev0
Expected behavior
Version name should be consistent of that assigned to.
How to Reproduce
Here is a minimum setup.py
Prior to 69.3.0, run
python setup.py sdist
produces a tarball nameddist/dumb-project-1.0.0.tar.gz
, as expected. Now, it produces a tarball named `dist/dumb-project-1.tar.gzOutput
setuptools 69.2.0
setuptools 69.3.0: