New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect removal of dash in case of pre-release tag string ? #524
Comments
At first glance i think setuptools scm is correct as it handles standard compliant python version numbers Those are not in line with semver |
After reading your conclusion I'll review the details and either fix this in a major release or document the choice |
Great ! Thanks for your reactivity @RonnyPfannschmidt . In the meantime I'll ship |
https://www.python.org/dev/peps/pep-0440/#pre-release-separators I believe that a decision on whether or not to normalise should be made Im leaning towards always normalising @jaraco any opinion on the way |
Note that a conservative move would be that you include a patched version scheme in the "alternate but built-in" version schemes of setuptool_scm : see my current dirty hack |
In general, I try to avoid normalizing user inputs, to honor the user's indication, and only to normalize in storage or comparison. However, the consensus from the Python community seems to be to prefer normalization early, to essentially disregard the user's intention and replace it with a normal form. It does seem to me to be a gap that the most popular versioning scheme (semver) is in conflict with the packaging normalization rules. I like the idea of providing an "alternate but built-in" version that's lenient to semver syntax. That would provide an opportunity to explore an implementation and to give users a nice escape hatch. I'd probably not recommend this except for very popular and compatible forms like semver. |
If a PR (with reasonable guidance) is needed at some point, let me know ! |
i would propose enabling users to supply own Version classes the only requirement being that the additionally i'm not opposed to provide a
|
I am not familiar enough with setuptools_scm internals but two things come to my mind, please discard them without caring if they do not apply because there is something I did not understand :
|
Preformat is unrelated to this issue Setuptools_scm should reject wrong versions So parsing is necessary A version subclass that stores the non normalised version seem to be a working solution |
How to turn off the version check? While I understand that people want consistency, I don't think hard policing version numbers is the job of SCM extraction tool. |
The standard tool setuptools-scm uses to parse valid versions does normalise, A new version of it that does not would have to be created as i mentioned earlier Ideally this happens upstream in packaging |
The tag is already a version string, so how to skip the upstream parser? It looks like |
Again, currently that's not implemented |
I've added some code to #555 but I have no setup ATM to test it works. |
Guys, checking this again I see that we have a valid proposal here: #524 (comment) My only concern would be about configuration: how would users be able to provide the custom class qualname in the For our use, we have |
I suspect not. Designing that interface would likely be part of this effort. |
The version class should be configured, it's up for discussion on where to put the non normalising version (packaging or setuptools_scm) I have a practical use case now (calver that keeps zero prefixes) |
I'll try to shoot a PR by tomorrow |
Lovely, I'll complete git archives support and get back to you |
I found this today:
1.0.0-rc1
becomes1.0.0rc1
, see details here smarie/python-getversion#10The underlying error is due to
pkg_resources
that removes the pre-release dash automatically in its string representation since version 0.6a9.However as suggested in my conclusions I think that the issue should probably better be fixed in the default scheme of setuptools_scm because faithfulness to git tags and compliance with
semver
for example, is probably a higher concern for you than forpkg_resources
.Thanks again for this great package !
The text was updated successfully, but these errors were encountered: