Use calendar versioning for Python package
Question:
I prefer the calendar versioning scheme (see calver.org) over the semantic approach. But when I use calendar versioning in a Python package, PyPI removes the zero padding in the month. For example, in setup.py
, if the version number is declared as version='19.03'
then PyPI hosts the package as 19.3 (no zero padding).
Is there a way to force PyPI to acknowledge the zero-padded month or is the YYYY.0M
scheme not supported for Python packages?
Answers:
Yes, it’s possible. The issue isn’t PyPI, it’s the way setuptools
normalizes the version number when building a distribution.
Take this simple setup.py
which defines a minimal package:
from setuptools import setup
setup(
name='calver-test',
version='2019.03.29',
packages=[],
)
If you run python setup.py sdist
, this will produce a file calver-test-2019.3.29.tar.gz
that has the following structure:
calver-test-2019.3.29
├── PKG-INFO
├── calver_test.egg-info
│ ├── PKG-INFO
│ ├── SOURCES.txt
│ ├── dependency_links.txt
│ └── top_level.txt
├── setup.cfg
└── setup.py
If you manually unpack the tar.gz
file, modify the occurrences of 2019.3.29
to 2019.03.29
in the PKG-INFO
files, and re-pack it into a file named calver-test-2019.03.29.tar.gz
, and upload it to PyPI, it will retain the zero padding.
Example here: https://pypi.org/project/calver-test/2019.03.29/
Obviously this process isn’t ideal if this is your intended behavior, so perhaps it would make sense to open an issue on the setuptools issue tracker.
For reference, to validate if the parsed version string is working as expected:
from pkg_resources import parse_version
assert parse_version("19.03" ) == parse_version("19.3")
assert (
parse_version("19.01")
< parse_version("19.02")
< parse_version("19.03")
< parse_version("19.04")
< parse_version("19.05")
< parse_version("19.06")
< parse_version("19.07")
< parse_version("19.08")
< parse_version("19.09")
< parse_version("19.10")
< parse_version("19.11")
< parse_version("19.12")
)
Ref: https://setuptools.pypa.io/en/latest/userguide/distribution.html
I prefer the calendar versioning scheme (see calver.org) over the semantic approach. But when I use calendar versioning in a Python package, PyPI removes the zero padding in the month. For example, in setup.py
, if the version number is declared as version='19.03'
then PyPI hosts the package as 19.3 (no zero padding).
Is there a way to force PyPI to acknowledge the zero-padded month or is the YYYY.0M
scheme not supported for Python packages?
Yes, it’s possible. The issue isn’t PyPI, it’s the way setuptools
normalizes the version number when building a distribution.
Take this simple setup.py
which defines a minimal package:
from setuptools import setup
setup(
name='calver-test',
version='2019.03.29',
packages=[],
)
If you run python setup.py sdist
, this will produce a file calver-test-2019.3.29.tar.gz
that has the following structure:
calver-test-2019.3.29
├── PKG-INFO
├── calver_test.egg-info
│ ├── PKG-INFO
│ ├── SOURCES.txt
│ ├── dependency_links.txt
│ └── top_level.txt
├── setup.cfg
└── setup.py
If you manually unpack the tar.gz
file, modify the occurrences of 2019.3.29
to 2019.03.29
in the PKG-INFO
files, and re-pack it into a file named calver-test-2019.03.29.tar.gz
, and upload it to PyPI, it will retain the zero padding.
Example here: https://pypi.org/project/calver-test/2019.03.29/
Obviously this process isn’t ideal if this is your intended behavior, so perhaps it would make sense to open an issue on the setuptools issue tracker.
For reference, to validate if the parsed version string is working as expected:
from pkg_resources import parse_version
assert parse_version("19.03" ) == parse_version("19.3")
assert (
parse_version("19.01")
< parse_version("19.02")
< parse_version("19.03")
< parse_version("19.04")
< parse_version("19.05")
< parse_version("19.06")
< parse_version("19.07")
< parse_version("19.08")
< parse_version("19.09")
< parse_version("19.10")
< parse_version("19.11")
< parse_version("19.12")
)
Ref: https://setuptools.pypa.io/en/latest/userguide/distribution.html