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

Future plans for versioneer #2853

Closed
djhoese opened this issue Mar 26, 2019 · 3 comments
Closed

Future plans for versioneer #2853

djhoese opened this issue Mar 26, 2019 · 3 comments

Comments

@djhoese
Copy link
Contributor

djhoese commented Mar 26, 2019

I have projects that use versioneer after finding out that xarray and dask used it. However, it seems the project is no longer actively maintained with the last commit happening almost 2 years ago:

https://github.com/warner/python-versioneer

There are two issues I've found with versioneer:

  1. Wheels do not have a valid version number. They get 0+unknown unless an sdist is built first to populate the egg info. Building sdist is not something that is always done by CI environments like travis. This also happens if someone installs the package from github pip install git+https://github.com/pydata/xarray.git. At least these are my findings with my satpy library.
  2. versioneer.py has some style issues:
versioneer.py:941:-13592: W605 invalid escape sequence '\s'
versioneer.py:941:-13408: W605 invalid escape sequence '\s'
versioneer.py:941:-13228: W605 invalid escape sequence '\s'
versioneer.py:941:-11196: W605 invalid escape sequence '\d'
versioneer.py:941:-8162: W605 invalid escape sequence '\d'

This was worked around in xarray by adding a noqa to the top of the module.

So my question is, do the xarray devs (or dask devs) see this as a problem? What are your plans for the future? Have you enjoyed using versioneer?

I guess I should probably CC @warner on this too in case they are still active on github.

@xhochy
Copy link

xhochy commented Mar 26, 2019

I'm really happy with https://pypi.org/project/setuptools-scm/ in other projects, especially as its usage is normally a single line in setup.py.

@max-sixty
Copy link
Collaborator

max-sixty commented Mar 26, 2019

Ditto @xhochy re setuptools-scm (though my experience is internally only, with more narrow requirements than a public project)

Our additional lines in setup.pys are only:

    install_requires=['setuptools_scm'],
    use_scm_version=dict(version_scheme='post-release'),

@keewis
Copy link
Collaborator

keewis commented Jul 26, 2020

I believe this has been fixed by moving to setuptools-scm in #3714.

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

No branches or pull requests

4 participants