8000 PEP-0440 compatibility: add git-describe's commit-distance as post-release/dev-release info by muggenhor · Pull Request #9 · python-versioneer/python-versioneer · GitHub
[go: up one dir, main page]

Skip to content

PEP-0440 compatibility: add git-describe's commit-distance as post-release/dev-release info #9

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

Conversation

muggenhor
Copy link
Contributor

PEP-0440 compatibility: add git-describe's commit-distance as post-release/dev-release info

This automatically creates post-release, development releases for the tag found and ensures they're PEP-0440 compatible to ensure tools like pip can work with them.

…lease/dev-release info

Signed-off-by: Giel van Schijndel <me@mortis.eu>
@warner
Copy link
Collaborator
warner commented Aug 28, 2013

I've rebased this to current (merging it with #10) and pushed to my "pr9" branch. Currently, tests fail. Looking into that now.

@warner
Copy link
Collaborator
warner commented Aug 28, 2013

I"m still studying the patch, but I think I'd like to add PEP440-compatible versions as an extra values in the dictionary of version strings, rather than replacing the existing one outright. I find the .post0.dev123 form frustrating to read, since it loses so much information.. I prefer git's tag-distance-ghash.

So I guess what I need to do is to document what exactly get_versions() returns: which values have which formats. That should make it easier to add a PEP440-compatible slot. And maybe we should change the installation process to make setup.py 's version= argument specifically use the PEP440 value instead of one of the other ones.

@warner
Copy link
Collaborator
warner commented Mar 11, 2014

I've update the docs to explain what get_versions() returns.. now I think there's room for a key named pep440. We may want to change the versioneer.py get_version() function (note: singular) to return the pep440 flavor instead of the current "version" flavor, or recommend that setup.py uses the plural get_versions() and then select the pep440 flavor explicitly.

@warner warner added this to the 0.11 milestone Mar 17, 2014
@sebastianneubauer
Copy link

What is the current status of the pep440 compliance? If it's not yet in, I would volunteer to help because it is a crucial feature for me to have versions which do not nuke pip...

@warner
Copy link
Collaborator
warner commented Jul 8, 2014

It's not in yet.. it got stalled a bit with the attempt to move to "templates".. take a look at https://github.com/warner/python-versioneer/tree/template and see if you can make any sense out of it. I need to spend a weekend doing a deep-dive on that branch and figure things out.. maybe in about three weeks I can get some time for it.

@tacaswell
Copy link

This is a duplicate feature to #45

@warner Would it be possible to prioritize this over the svn/template related work?

I am willing and able to dump time into either of this PRs if you want/need.

@sebastianneubauer
Copy link

I would as well have some spare time to improve on the pep440 issue, some effort is still needed in my PR #45 to be fully mergable! @warner whats your opinion, is it worth to invest time now?

@warner
Copy link
Collaborator
warner commented Feb 13, 2015

I think PR #67 took care of this.

@warner warner closed this Feb 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0