lib: follow PEP440 closer, handle -dirty#1547
lib: follow PEP440 closer, handle -dirty#1547parona-source wants to merge 1 commit intogentoo:masterfrom
Conversation
If using the live package at a commit that has been tagged it would lead to a version like 3.0.77-dirty. Which would be an invalid version in the python ecosystem and pip check would complain. Handle that specific scenario explicitly and while at it use .dev for the "commit since tag" marker since its strictly more correct. setuptools-scm handles it like this as well. Example version before change: 3.0.77-dirty 3.0.77-4+g78ec6ee6b Example versions after change: 3.0.77+dirty 3.0.77.dev5+g0f06e2826 Signed-off-by: Alfred Wingate <parona@protonmail.com>
|
Shouldn't dirty only be applicable specifically to cases where one has applied PATCHES=() or /etc/portage/patches (or a sed in src_prepare), and have nothing to do with whether it has been tagged (except that building portage from something other than a tag already has to do post-processing of the commit info, and as a side effect causes dirty to not be an issue)? |
Yeah, I shouldve been clearer that it was a case building at a tag and having non vcs changes applied at the same time.
Yeah |
2 participants
If using the live package at a commit that has been tagged it would lead to a version like 3.0.77-dirty. Which would be an invalid version in the python ecosystem and pip check would complain.
Handle that specific scenario explicitly and while at it use .dev for the "commit since tag" marker since its strictly more correct. setuptools-scm handles it like this as well.
Example version before change:
3.0.77-dirty
3.0.77-4+g78ec6ee6b
Example versions after change:
3.0.77+dirty
3.0.77.dev5+g0f06e2826