tests missing in sdist/ incoherent tagging vs tarball naming

[dvzrv]

Hi! I'm packaging python-publisuffx2 for Arch Linux and would like to be able to run tests from the sdist tarball on pypi.
Although the test files should be included (according to MANIFEST.in), they are not.

As a test I've checked out the current latest version (release-2.2019-12-21) and ran python setup.py sdist myself. The files are included in the created sdist tarball, which makes me wonder how the sdists for pypi.org were created.

It would be great, if the sdists included the tests, as currently I have to use the github tarballs to be able to run the tests.

This leads me to the second topic: The tag naming and resulting tarballs are incoherent and lead to more complicated string substitutions to track upstream and/or use the github source tarball vs. using pypi's sdist tarball: release-2.2019-12-21 -> publicsuffix2-2.20191221.tar.gz
I understand, that the tagging scheme so far follows an ISO standard for the date, but it would be more coherent to strip the hyphens to be in line with the resulting tarball/wheel: e.g. release-2.20191221 -> publicsuffix2-2.20191221.tar.gz

[pombredanne]

@dvzrv thank you ++ as it happens @kitterma just contributed the manifest fix to include the tests in #11 and this is being merged in #13

The files are included in the created sdist tarball, which makes me wonder how the sdists for pypi.org were created.

It is created exactly with python setup.py sdist

This leads me to the second topic: The tag naming and resulting tarballs are incoherent and lead to more complicated string substitutions to track upstream and/or use the github source tarball vs. using pypi's sdist tarball: release-2.2019-12-21 -> publicsuffix2-2.20191221.tar.gz
I understand, that the tagging scheme so far follows an ISO standard for the date, but it would be more coherent to strip the hyphens to be in line with the resulting tarball/wheel: e.g. release-2.20191221 -> publicsuffix2-2.20191221.tar.gz

that's as benign as it gets! let me fix that... @kitterma I assume that will be better for Debian versions too, correct?

[kitterma]

The Debian watch file (what we use to detect if there is a new version available) looks for a new tarball on pypi. As a result, the tag naming doesn't affect us directly. The only critical point for Debian and version numbers is that they always go up.

[dvzrv]

Arch Linux now has entirely dropped the use of PyPI sdist tarballs: https://rfc.archlinux.page/0020-sources-for-python-packaging/

A more coherent tagging scheme would therefore be awesome (e.g. following calver)! :)

[pombredanne]

@dvzrv what would you suggest? It feels weird if the tagging scheme is adjusted for one distro through. This is the continuation of the prior one mostly.

[dvzrv]

Well, we are also watching PyPI for releases, but with the described translation problem (2.20191221 (PyPI version) -> release-2.2019-12-21 (tag in repo)) it gets rather hard to build from this source repository (or its source tarballs. We have to insert several - into the version string gotten from PyPI and that feels unnecessarily brittle tbh.

If the tagging scheme matches that of the versioning scheme on PyPI (can be with prefix), that would be helpful. E.g. instead of release-2.2019-12-21 you'd use release-2.20191221

This is the continuation of the prior one mostly.

Yeah, but does it have to be kept? :)

[dvzrv]

To illustrate: we currently have to do

foo="2.20191221"
echo "${foo:0:2}${foo:2:4}-${foo:4:2}-${foo:6:2}"
2.2019-19-12