Use versioneer to manage __version__

[martinfleis]

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

2. 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.

3. Run versioneer from root folder

versioneer install .

4. 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.

5. 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]

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

[martinfleis]

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]

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.

[ljwolf]

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?

[jGaboardi]

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

[martinfleis]

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

[sjsrey]

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

[jGaboardi]

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

No rush at all. Hope everything is OK.

[sjsrey]

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.