packaging: use a PEP 440 compliant version string about openscanhub HOT 10 CLOSED

As mentioned in the PEP: Many build tools integrate with distributed version control systems like Git and Mercurial in order to add an identifying hash to the version identifier. As hashes cannot be ordered reliably such versions are not permitted in the public version field.

So, commit hashes are not allowed in versions of Python packages. What we can do is to use dev releases like X.Y.Z.devN where N is a number of commits since the last release. But that works only if the history is stable so only for the main branch I guess.

Or, if we don't need the version string to be the same for the Python package and the RPM package, we can add a date and git commit hash only into RPM, see https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_complex_versioning_with_a_pre_and_post_release_snapshots

Thanks to the date part of the snapshot after the version itself, the string is sortable. The logic doing that in setup.py can be extracted to a script that would produce the version we can then prepend to the specfile so only the RPMs are versioned with the snapshot.

Is this something you'd like me to take a look at? I cannot promise it in the next two weeks but it should not be a problem.

from openscanhub.

@frenzymadness Is there any project that uses setuptools to create snapshots from git in a way that version strings for commit objects created/amended later are seen by dnf as updates of previously installed snapshots?

from openscanhub.

The main problem with the Python versioning facility is that a version string that was valid yesterday is not valid today. We have used the scheme {last_git_tag}.{commit_date}.{commit_time}.g{hash} since 2011 without any issues. A year ago you helped us to make the scheme more Python-friendly. Now we are forced to change the scheme again, which will again make the version strings incomparable with both the previous schemes.

If I read https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots correctly, it does not allow us to encode {commit_date}.{commit_time} into the version string any more?

from openscanhub.

If I read https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots correctly, it does not allow us to encode {commit_date}.{commit_time} into the version string any more?

It seems that only date is allowed, not time. The current master snapshot can have for example 0.9.3^20230810gitddbc314 or 0.9.3^20230810.ddbc314.

I think that we can follow the PEP for Python package versioning (which would always produce the latest version identifier without any snapshot information) and the versioning scheme mentioned above for RPM packages.

from openscanhub.

Is that a problem? I mean, do you use Python packages (sdist, wheels) directly anywhere?

from openscanhub.

I think we do not use the Python packages anywhere for now. We use the code in question for setup.py sdist --formats=bztar to create the source code tarball with a file name that matches the NVR used by the RPM packaging.

from openscanhub.

That's what I thought so the proposed solution should work.

from openscanhub.

Note that 2023-Sep-26 will be next week.

from openscanhub.

The builds are now failing due to this issue: https://github.com/openscanhub/openscanhub/runs/18347137531

from openscanhub.

I have submitted #172 to fix this.

from openscanhub.