[BUG] tarball version suffix get trimmed

[Abacn]

setuptools version

69.3.0 and above

Python version

Python 3.8

OS

Linux / macOS / windows

Additional environment information

No response

Description

Found in apache/beam#30955,

setuptools trim the version number of ".0" when tarball gets built

If the package version is 1.0.0, now, it trimmed to 1.

If the package version is 1.0.0.dev0, now, it trimmed to 1.dev0

Expected behavior

Version name should be consistent of that assigned to.

How to Reproduce

Here is a minimum setup.py

import setuptools

setuptools.setup(
    name="dumb-project",
    version="1.0.0",
    description="test project",
    install_requires=[]
)

Prior to 69.3.0, run python setup.py sdist produces a tarball named dist/dumb-project-1.0.0.tar.gz, as expected. Now, it produces a tarball named `dist/dumb-project-1.tar.gz

Output

setuptools 69.2.0

python setup.py sdist
running sdist
running egg_info
writing dumb_project.egg-info/PKG-INFO
writing dependency_links to dumb_project.egg-info/dependency_links.txt
writing top-level names to dumb_project.egg-info/top_level.txt
reading manifest file 'dumb_project.egg-info/SOURCES.txt'
writing manifest file 'dumb_project.egg-info/SOURCES.txt'
warning: sdist: standard file not found: should have one of README, README.rst, README.txt, README.md

running check
creating dumb-project-1.0.0
creating dumb-project-1.0.0/dumb_project.egg-info
copying files to dumb-project-1.0.0...
copying setup.py -> dumb-project-1.0.0
copying dumb_project.egg-info/PKG-INFO -> dumb-project-1.0.0/dumb_project.egg-info
copying dumb_project.egg-info/SOURCES.txt -> dumb-project-1.0.0/dumb_project.egg-info
copying dumb_project.egg-info/dependency_links.txt -> dumb-project-1.0.0/dumb_project.egg-info
copying dumb_project.egg-info/top_level.txt -> dumb-project-1.0.0/dumb_project.egg-info
copying dumb_project.egg-info/SOURCES.txt -> dumb-project-1.0.0/dumb_project.egg-info
Writing dumb-project-1.0.0/setup.cfg
Creating tar archive
removing 'dumb-project-1.0.0' (and everything under it)

setuptools 69.3.0:

$ python setup.py sdist
running sdist
running egg_info
writing dumb_project.egg-info/PKG-INFO
writing dependency_links to dumb_project.egg-info/dependency_links.txt
writing top-level names to dumb_project.egg-info/top_level.txt
reading manifest file 'dumb_project.egg-info/SOURCES.txt'
writing manifest file 'dumb_project.egg-info/SOURCES.txt'
warning: sdist: standard file not found: should have one of README, README.rst, README.txt, README.md

running check
creating dumb_project-1
creating dumb_project-1/dumb_project.egg-info
copying files to dumb_project-1...
copying setup.py -> dumb_project-1
copying dumb_project.egg-info/PKG-INFO -> dumb_project-1/dumb_project.egg-info
copying dumb_project.egg-info/SOURCES.txt -> dumb_project-1/dumb_project.egg-info
copying dumb_project.egg-info/dependency_links.txt -> dumb_project-1/dumb_project.egg-info
copying dumb_project.egg-info/top_level.txt -> dumb_project-1/dumb_project.egg-info
copying dumb_project.egg-info/SOURCES.txt -> dumb_project-1/dumb_project.egg-info
Writing dumb_project-1/setup.cfg
Creating tar archive
removing 'dumb_project-1' (and everything under it)

[tvalentyn]

cc: @jaraco

[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.

[mtelka]

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.

[jaraco]

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.

[tvalentyn]

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.

[jaraco]

Yes, that seems sensible. I've yanked the 69.3 and 69.4 releases.