Hi, Am 09.07.21 um 12:43 schrieb Martin Wilck:
The "duplicity" package uses python's setuptools_scm module to substitute the package version in its own sources.
For development versions that aren't tagged, setuptools_scm uses the format "$NEXT_VERSION.dev$N", where NEXT_VERSION is the guessed subsequent/future version, and $N is the commit distance from the last released version.
This scheme doesn't work with rpm. AFAIK, for rpm we must use $NEXT_VERSION~$N instead to achieve the desired ordering:
$CURRENT_VERSION < $NEXT_VERSION~$N < $NEXT_VERSION~$((N+1)) < $NEXT_VERSION
Unfortunately the ".dev" format is hard-coded in setuptools. Has anyone encountered this issue before? Is there a smart solution to modify setuptools' behavior, or some other trick?
Regards Martin
Please don't modify setuptool's behavior. This would lead to issues with importlib whenever a package requests a module and finds some unexpected version scheme in the dist-info/egg-info metadata. It's a common pattern to use $NEXT_VERSION~$suffix for pre-releases and $CURRENT_VERSION+$suffix for post releases and git commits after a release. The setuptools version used in the egg-info/dist-info metadata and the RPM version don't have to be exactly the same. As duplicity uses the obs_scm service, you have to adjust the "versionrewrite-pattern" and "versionrewrite-replacement" tags. Check these sections of PEP440: https://www.python.org/dev/peps/pep-0440/#normalization https://www.python.org/dev/peps/pep-0440/#summary-of-permitted-suffixes-and-... HTH, Ben