Skip to content

Conversation

@Sulley38
Copy link
Contributor

@Sulley38 Sulley38 commented Dec 6, 2017

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

Closes #511

@pganssle
Copy link
Member

pganssle commented Dec 7, 2017

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
Copy link

joguSD commented Apr 23, 2018

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
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
Copy link

joguSD commented Apr 24, 2018

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