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

[jaraco]

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.

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.

[jaraco]

I'm releasing v69.3.1 and v69.4.1 with hotfixes for this issue. Version numbers will once again retain trailing zeros.

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

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.