You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider some random python module that is in a git-versioned folder, tagged as 1.0.0-rc1 (release candidate. See semantic versioning: https://semver.org/spec/v2.0.0-rc.1.html)
The following code does not retrieve the right version string: the dash before the pre-release info is removed
fromgetversionimportget_module_version# import whatever local folder or file is available in this git folderimportmy_module# get the version and details. it will fallback to using the setuptools_scm onever, details=get_module_version(my_module)
print(details) # SUCCESS on the setuptools_scm one (the last one)print(ver) # prints "1.0.0rc1" instead of "1.0.0-rc1"
This has for example as consequence that the resulting version string is not compliant with semver while the initial git tag was:
from semver import parse_version_info
parse_version_info("1.0.0-rc1") # this is ok
parse_version_info("1.0.0rc1") # this fails
raises ValueError: 1.0.0rc1 is not valid SemVer string
The text was updated successfully, but these errors were encountered:
getversion delegates to its plugin_setuptools_scm.py that calls setuptools_scm.get_version(<root_folder>)
setuptools_scm.get_version :
executes git describe --dirty --tags --long --match *.* to get the correct version number 1.0.0-rc1
uses pkg_resources.parse_version(version_string) to get a Version object with the correct information, and stores it in it own wrapping object's version.tag attribute.
uses the string representation (__str__) of this Version object in the various "version scheme" string formatting methods
The issue is that since pkg_resources version 0.6a9 the string representation of a Version removes the dash !!
to secure the usage of the output of get_version for use for example with semver, I will add today a fix that will use a custom version scheme.
this could be fixed in setuptools_scm. It would be my preferred option, since the default versioning scheme should probably closely match the tag actually visible in github, without removing dashes.
this could be fixed in pkg_resources. I am not sure that this should/could happen for retrocompatibility issues, and since this is not at all tied to git scm
Consider some random python module that is in a git-versioned folder, tagged as
1.0.0-rc1
(release candidate. See semantic versioning: https://semver.org/spec/v2.0.0-rc.1.html)The following code does not retrieve the right version string: the dash before the pre-release info is removed
This has for example as consequence that the resulting version string is not compliant with
semver
while the initial git tag was:raises
ValueError: 1.0.0rc1 is not valid SemVer string
The text was updated successfully, but these errors were encountered: