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

use versioneer to manage __version__ #981

Merged
merged 5 commits into from
Aug 21, 2019
Merged

use versioneer to manage __version__ #981

merged 5 commits into from
Aug 21, 2019

Conversation

zsol
Copy link
Collaborator

@zsol zsol commented Aug 13, 2019

  • For releases made from a tagged commit, __version__ doesn't change.
  • For releases made from all other commits, __version__ changes to ${TAG}+${COMMITS_SINCE}.g${SHA}${DIRTY} (TAG = most recent tag, COMMITS_SINCE is the number of commits since $TAG, SHA is the output of git rev-parse HEAD, DIRTY is .dirty if the working copy has uncommited changes), for example: 19.3b0+77.gf1a148e.dirty
  • This PR also changes the version string used for Black's cache to be $SHA.

Fixes #980

@zsol zsol merged commit 025d2ca into master Aug 21, 2019
@zsol zsol deleted the versions branch August 21, 2019 13:42
@vezeli
Copy link
Contributor

vezeli commented Sep 2, 2019

Alternative to the versioneer for dealing with version tracking would be to consider using setuptools-scm. setuptools-scm is a part of the setuptools it does everything in the background so that there is no need for polluting the package with _version.py and versioneer.py.

Maybe I am missing something but was there (or is there still) a strong reason against it setuptools-scm?

@zsol
Copy link
Collaborator Author

zsol commented Sep 3, 2019

I'll be honest I haven't found setuptools-scm, so didn't really evaluate it

@vezeli
Copy link
Contributor

vezeli commented Sep 3, 2019

Oh I see :)

The final result would be the same, i.e. black.__version__ will change on every commit in line with the SHA-1 (as needed for #980). The main advantage, however, is that setuptools-scm comes together with setuptools so there is no need to put a big script such as versioneer.py in the package directory next to the main script. Although one could still keep the _version.py since setuptools-scm creates it in the process of package setup (otherwise one could also put it in .gitignore for the purpose of development).

E.g. borg project switched from versioneer to setuptools-scm borgbackup/borg/pull/161 due to the borgbackup/borg/issues/106.

@hugovk
Copy link
Contributor

hugovk commented Sep 4, 2019

setuptools_scm is great for autoversioning, but comes with an extra big bit of functionality to watch out for.

It automatically adds all of the SCM-managed files to the sdist.
Unwanted files must be excluded by discarding them via MANIFEST.in.

My advice is to create an sdist and diff it with an old one, then add excludes to MANIFEST.IN until they match.

@zsol
Copy link
Collaborator Author

zsol commented Sep 4, 2019

I'm happy to review a PR that switches us over. The main reason versioneer was introduced in a rush is to unbreak people using a non-release version of Black.

@vezeli
Copy link
Contributor

vezeli commented Sep 4, 2019

Sounds good, I can give it a try :)

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.

'Symbols' object has no attribute 'namedexpr_test'
3 participants