added pep440 compliance option #45
Conversation
|
As I read PEP440, the only option for release_type_string that makes sense is 'post', I think. 'dev' does not work here, since dev releases are ordered before the non-dev release. I.e. suppose I tag and release a version 1.2. Then I make another commit. I want the version to now be 1.2.post1. 1.2.dev1 does not work since 1.2.dev1 < 1.2 according to PEP440. Or am I confused? |
|
Yes, sorry, we already found out the same, PEP440 is really weird in this. What works best is: "a.b.c.post.devXX" is what works best, it says we are after version a.b.c. But we don't know yet what the next stable version will be, could be a.b.c+1, or a.b+1.0 for example, of course versioneer cannot guess if there will be breaking changes. But PEP440 exactly requires that guessing, "a.b.c.dev" says, we are aiming a.b.c, but we are not there yet. Furthermore "dev" says this is not a stable version so pip install will ignore it without the "--pre" flag |
|
Yeah, I can see either M.N.postXX or M.N.post.devXX working well, depending on the projects development model. Some might like each commit to be a "lightweight commit" (e.g. if one requires tests to pass before each commit) in which case M.N.postXX makes sense. As another data point, my gitversion.py script (which I am not recommending to anyone — I came here looking for a better replacement) uses the M.N.postXX scheme, and tags the -dirty builds with M.N.post<XX+1>.dev. Anyhow, I'd be happy with either scheme. But not having PEP440 compliant version numbers is a show-stopper for me. |
|
What about make this postfix configurable with a reasonable default value? It reflects pretty much the individual workflow of a project (e.g. -dirty->dev ist really an option for us, as technically each release is committed, but not each commit is a stable version) and therefore has to be individual as well... |
|
|
||
| def git2pep440(ver_str): | ||
| try: | ||
| tag, commits, _ = ver_str.split('-', 2) |
There was a problem hiding this comment.
PEP 440 has support for 'local versions' https://www.python.org/dev/peps/pep-0440/#adding-local-version-identifiers. I suggest that this be re-written something like
tag, commits, local = ver_str.split('-', 2)
return "{}.{}{}+{}".format(tag, release_type_string, commits, local)There was a problem hiding this comment.
just to get it right, you mean adding +revname (e.g. g12345) as local version? What would that add? Or just as convenience for finding the git revision by the version name? But that would not be the intension of PEP local versions. I have't looked into it deeper, just by looking at the functions I doubt that there are good unit tests prooving what could happen there, so maybe I'm just wrong what the outcome of your suggestion would be...
But in principle I agree
There was a problem hiding this comment.
Yes, the point is to have the git sha in the version to get around the issue that the commits count only counts from the last tag so if you build out of two different branches they can have the same number of commits. Tacking the sha on won't help pip and automatic tools for sorting but will a) give humans a prayer of sorting out what is going on (as a maintainer, this could really help with bug reports) and b) allow you to specify the full version (including the sha) if you really cared.
I think the point of the 'local version' is to allow downstream packagers to version their packages (either for build reasons or patch reasons) is such a way that does not tramp on the upstream versions. What I am proposing is an abuse of this, but a very useful abuse.
In an attempt to appeal to authority, scipy has just started doing this: https://github.com/scipy/scipy/pull/4307/files
There was a problem hiding this comment.
Sounds really usfull for me too1 I haven't yet come into the problem of making releases from different branches (only from the mainline) but I agree this might be a totally valid need! But would you agree that it should be optional?
There was a problem hiding this comment.
+1 on @tacaswell's proposal. I don't think there's any need to make it optional, not more than in the current versioneer behaviour.
|
Is there anything I / we can do to help move this along? This would be very useful for me. |
Allows versions to continue working for a checked out source tree when the package was discovered by Python via a symlink.
|
As far as I can tell this pull does not propagate |
|
I found that out recently too and started to fix it, but then found out, that versioneer is far more complicated than I expected at first glance. I would need some more guidance on how to fix it...BTW is the project still active, i.e is it worth the time to investigate it? Is this feature still needed for someone? |
|
I certainly do have use for this feature, and I have otherwise found versioneer very useful. I hope the project does keep going. |
|
Getting _version.py to also do the right thing seems to just require making a similar set of updates to Also, personally I would prefer that versioneer treat all of the git-describe information as a local version - i.e. "1.2.1+29.gd1e4bf4" rather than "1.2.1.post.dev29+gd1e4bf4". This also seems the least likely to interfere with anyone's versioning scheme (i.e., if someone is already using "dev" and "post" in their release tags). Here's how I implemented it: |
|
Am I wrong, or is the part behind '+' just ignored by pip? Would that mean that all versions after a tagged version are equal? How can I prevent being installed by pip only with --pre if not a tagged version? The exact string between version and commit distance is configurable, default is '.post.dev', changing it to '.post' would make the version a stable one if you need this behaviour, a,b, rc wold be other options...BTW: this revision works now for me and is now the default, pep440 can be switched of via configuration |
|
I think the part after the |
|
Ok, I think PR #67 subsumed this. The new template branch should make it possible to get other formats, including .post.dev, so once that lands, I think it should be easy to get the workflows above. |
Hi, we have added some functionalty to replace the version string git commit number with a more pep440 compliant 'dev'. There is also the option to replace 'dev' with a string of your choice (e.g. 'post'). This can be configured via the two new header.py variables:
We can see there is some major refactoring in progress in the 'template' branch, but we hoped it would be possible to incorporate these small updates to the master. No test for 'git2pep440', but can be added if you agree to incorporate the changes.