Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Use versioneer to manage __version__ #429

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.

Sign up for GitHub

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

Jump to bottom
Merged
jGaboardi merged 1 commit into from
Sep 11, 2021
Merged

Use versioneer to manage __version__ #429

jGaboardi merged 1 commit into from
Sep 11, 2021

Conversation

@martinfleis
Copy link
Member

@martinfleis martinfleis commented Sep 3, 2021

Following today's chat on using automatised way of __version__ management, this adds versioneer-based implementation.

It is a pretty straightforward PR.

  1. install versioneer
pip install versioneer
  1. add setup.cfg with the following contents
[versioneer]
VCS = git
style = pep440
versionfile_source = libpysal/_version.py
versionfile_build = libpysal/_version.py
tag_prefix = v
parentdir_prefix = libpysal-

Each project should replace lipbysal with the relevant name here.

  1. Run versioneer from root folder
versioneer install .
  1. edit setup.py

Remove reading of version from __init__:

- # Get __version__ from libpysal/__init__.py without importing the package
- # __version__ has to be defined in the first line
- with open("libpysal/__init__.py", "r") as f:
-     exec(f.readline())

Import versioneer and use it within setup():

import versioneer

...

setup(
    ...
    version=versioneer.get_version(),
    cmdclass=versioneer.get_cmdclass({"build_py": build_py}),  
    ...)

I am wrapping existing {"build_py": build_py} in versioneer's one.

  1. Remove hardcoded __version__ from __init__.py

Everything else is automated. For details, see the changes in this PR.

How it works:

In [1]: import libpysal

In [2]: libpysal.__version__
Out[2]: '4.5.1.post2+23.gb400dc0e'

4.5.1.post2 is the latest tag, 23 is the number of commits since that tag, gb400dc0e is the ID of the latest commit.

To use it across pysal ecosystem, we will need to do the same in all packages and probably change some meta-package machinery that may expect __version__ in a different way.

jGaboardi
jGaboardi reviewed Sep 3, 2021
View reviewed changes
Copy link
Member

@jGaboardi jGaboardi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@martinfleis Would else anything need to change (e.g. in conf.py)?

@martinfleis
Copy link
Member Author

martinfleis commented Sep 3, 2021

Everything that uses libpysal.__version__ should be fine. We need to update only those bits that read the first line of the init with the hardcoded version. I think that everything else uses libpysal.__version__.

@jGaboardi
Copy link
Member

jGaboardi commented Sep 3, 2021

Everything that uses libpysal.__version__ should be fine. We need to update only those bits that read the first line of the init with the hardcoded version. I think that everything else uses libpysal.__version__.

I'm for trying it.

@jGaboardi jGaboardi mentioned this pull request Sep 5, 2021
Closed
@ljwolf
Copy link
Member

ljwolf commented Sep 8, 2021 •
edited
Loading

Well, as far as I can tell, the current version of the release scripts actually uses the github api to build the version list, not the first line of the __init__.py @sjsrey would know a bit more though about the release materials, though.

This means that (a) starting versioneer in one package should not break its compatibility with the metapackage scripts and (b) we don't have to adopt versioneer everywhere, if need be.

That makes this very desirable... So, I propose:

  1. we merge this
  2. I cut the release of libpysal including @knaaptime's speedup to W.full().
  3. I check the metapackage build to see if it works with libpysal using versioneer.

@sjsrey, does this look ok to you?

@ljwolf ljwolf mentioned this pull request Sep 9, 2021
Merged
@jGaboardi
Copy link
Member

jGaboardi commented Sep 11, 2021

Shall we go ahead and merge this or should we wait for @sjsrey's explicit approval?

@jGaboardi jGaboardi mentioned this pull request Sep 11, 2021
Merged
@martinfleis
Copy link
Member Author

martinfleis commented Sep 11, 2021

I'd wait for @sjsrey because he wasn't present at the last meeting when we discussed this.

@sjsrey
Copy link
Member

sjsrey commented Sep 11, 2021

Will look at this tomorrow. Been occupied with family/life issues for a few weeks.

@jGaboardi
Copy link
Member

jGaboardi commented Sep 11, 2021

Will look at this tomorrow. Been occupied with family/life issues for a few weeks.

No rush at all. Hope everything is OK.

@sjsrey
Copy link
Member

sjsrey commented Sep 11, 2021

I think this should be merged as it is a much-improved way to handle the versioning. There are likely to be some rough edges in the ecosystem (maybe in the doc generation and perhaps the meta release) but these should be adjusted to adopt this approach.

@jGaboardi jGaboardi merged commit 2cc0c7c into pysal:master Sep 11, 2021
@jGaboardi jGaboardi mentioned this pull request Sep 11, 2021
Merged
This was referenced Sep 12, 2021
Closed
Merged
@martinfleis martinfleis deleted the versioneer branch December 3, 2021 16:23
@knaaptime knaaptime mentioned this pull request Jan 28, 2022
Closed
@jGaboardi jGaboardi mentioned this pull request Jul 23, 2022
Closed
@jGaboardi jGaboardi mentioned this pull request Jan 13, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@knaaptime knaaptime knaaptime approved these changes

@jGaboardi jGaboardi jGaboardi approved these changes

@ljwolf ljwolf Awaiting requested review from ljwolf

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@martinfleis @jGaboardi @ljwolf @sjsrey @knaaptime