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?

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

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.

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.

• experiment with better describing the file finding pypa/setuptools-scm#343
• https://twitter.com/ZaneSelvans/status/1143976645981876224

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.

Sounds good, I can give it a try :)