Skip to content

Generate version numbers from git metadata#564

Merged
pganssle merged 2 commits into
dateutil:masterfrom
Sulley38:setuptools-scm
Dec 7, 2017
Merged

Generate version numbers from git metadata#564
pganssle merged 2 commits into
dateutil:masterfrom
Sulley38:setuptools-scm

Conversation

@Sulley38

@Sulley38 Sulley38 commented Dec 6, 2017

Copy link
Copy Markdown
Contributor

The format is described in https://github.com/pypa/setuptools_scm, Section "Default versioning scheme".

Closes #511

@pganssle

pganssle commented Dec 7, 2017

Copy link
Copy Markdown
Member

This is weird, I'm not entirely sure where setuptools_scm is coming from when I do the build, but it certainly doesn't seem to install anything at build time, so let's see how this goes! Thanks @Sulley38

@pganssle
pganssle merged commit ed4a2b4 into dateutil:master Dec 7, 2017
@pganssle pganssle added this to the 2.7.0 milestone Dec 7, 2017
@pganssle pganssle added the build label Dec 7, 2017
@pganssle pganssle mentioned this pull request Mar 11, 2018
@joguSD

joguSD commented Apr 23, 2018

Copy link
Copy Markdown

As far as I can tell, setuptools will actually download & install setuptools_scm at build time if it's not already present. I'm not sure if adding this kind of build time dependency is worth it to avoid having to manage version numbers manually.

@pganssle

Copy link
Copy Markdown
Member

Yes, setuptools_scm is a pypa project for simplifying version number management, and it is installed if necessary. I'm not terribly worried about a small build-time dependency like this. The vast majority of people install from the universal wheel or through a platform's package manager (e.g. conda, debian, etc). I've heard no complaints about it and it makes dev versions in particular very convenient to differentiate between, which is useful for people who might be testing against master and opting in to unreleased features.

The major upside is that the version is specified exactly one place - in the SCM metadata - and everywhere else it appears is derived from that.

The major downside from my perspective is that the release version number does not actually appear in the git data in any way, so a snapshot of the library's contents from a given period in time, independent of the git repository, will not actually allow you to build the library as it appeared at that time. I think this is a minor problem, though I suppose with the right automation procedures it could be remedied in some way without doing it manually.

@joguSD

joguSD commented Apr 24, 2018

Copy link
Copy Markdown

Thanks for taking the time to reply. One pain point having a setup_requires introduces is installing a package that has a dependency with a setup_requires from a local index no longer works. Something like:

pip install --no-index --find-links file://./packages package-x.y.z.tar.gz

Where ./packages has all required packages (even those defined in setup_requires). You have to explicitly install any and all setup_requires dependencies before attempting to install the desired package, otherwise setuptools will attempt to download the package ignoring the local index. Using wheels does side-step this problem though.

@pganssle

Copy link
Copy Markdown
Member

@joguSD That seems like a problem with pip or with setuptools. Have you tried taking this to pypa/packaging-problems?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants