Skip to content
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

bioconda_utils.version gets out of sync -> use versioneer? #261

Merged
merged 1 commit into from
Jan 31, 2018

Conversation

mbargull
Copy link
Member

https://github.com/bioconda/bioconda-utils/blob/v0.11.4/bioconda_utils/version.py still says 0.11.1.

What do you think about using versioneer to have a set-and-forget solution so we don't have to manually maintain that anymore ourselves?

@kyleabeauchamp
Copy link
Contributor

Do folks have any thoughts on versioneer vs pbr (https://docs.openstack.org/pbr/latest/)? I've had reasonable (but not awesome) experiences with both, so figured I'd run a quick survey...

@johanneskoester
Copy link
Contributor

Crazy, all this code for just a version. Is it less with PBR?

@kyleabeauchamp
Copy link
Contributor

I also found PBR to be kinda heavyhanded, but we use it a bit here: https://github.com/counsyl/stor/. The setup.py at least is minimal (https://github.com/counsyl/stor/blob/master/setup.py#L5)

@mbargull
Copy link
Member Author

Crazy, all this code for just a version.

Ye, it's one big blob. But I find versioneer comparatively unintrusive. It's easy to revert to previous behavior since you essentially just need to alter two setup keywords an a variable assignment (and ofc delete those big static files).
It is a bit strange at first that you have to add those big versioneer.py/_version.py to the code base. But due to being selfcontained, the advantage with that is that you don't have introduce any external dependencies (e.g., via setup_requires) during the setup.
In short: Just think of it as a dependency that you vendor to avoid any complications during setup.
As for the final build, that _version.py will just be replaced by

# This file was generated by 'versioneer.py' (0.18) from
# revision-control system data, or from the parent directory name of an
# unpacked source archive. Distribution tarballs contain a pre-generated copy
# of this file.

import json

version_json = '''
{
 "date": "2018-01-30T18:47:45+0100",
 "dirty": false,
 "error": null,
 "full-revisionid": "86ed9ccfc35acf65000c6d2c794ff24160560c51",
 "version": "0.11.4+2.g86ed9ccf"
}
'''  # END VERSION_JSON


def get_versions():
    return json.loads(version_json)

(The only strange thing with that is the json usage, IMO...)

As for pbr: I never tried that out so can't really say anything about that. But I also wasn't too keen to try it out as it's a bit more intrusive...

@mbargull
Copy link
Member Author

On a second though about PBR being more intrusive: This might've been more applicable a few years back. Now (already for quite some time) that setuptools supports metadata from setup.cfg, that is less the case. Though, as said before, I can't really tell since I never used it.

@mbargull
Copy link
Member Author

A main plus for versioneer some time back was to avoid those setup_requires dependencies. If you use conda-build that is, of course, not really a big deal anymore.

Overall I think it's very beneficial to have something inplace that lets us avoid that redundancy/potential inconsistency in the release process -- but I don't really mind what technique we use (as long as it's reliable).

@kyleabeauchamp
Copy link
Contributor

Anything SGTM, I just wanted to hear some folks' opinions on the matter.

@johanneskoester johanneskoester merged commit 4f68b33 into master Jan 31, 2018
@johanneskoester
Copy link
Contributor

Ok, merged. Let's use versioneer :-).

@johanneskoester johanneskoester deleted the versioneer branch January 31, 2018 10:30
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.

3 participants