bad interaction with setuptools_scm

[brianmay]

It looks like readthedocs alters docs/conf.py before building documentation.

This in turn means that setuptools_scm detects the change and changes the version number. This behaviour is incorrect.

Is it possible that readthedocs could copy the file to somewhere else (maybe outside the tree) before making modifications?

References:
http://stackoverflow.com/questions/35811267/readthedocs-and-setuptools-scm-version-wrong/36386177
pypa/setuptools-scm#84

[agjohnson]

I'm not entirely familiar with setuptools_scm, but seems like what we want to is to make sure we're patching conf.py after any operations to setup.py? Moving to a separate location isn't likely to solve anything without ordering these commands differently. This may be a case of altering the conf.py file outside our build containerization, in which case, it would always happen before setup.py is evaluated.

[brianmay]

While the version is evaluation occurs when setup.py is executed, it is also re-evaluated when conf.py is executed. So at the time conf.py is executed there shouldn't be modified tracked files in the git working directory (untracked files appear to be ok).

My work around for now is to renamed conf.py to conf.orig.py and have setup.py copy it back to conf.py. It does work, but seems kind of messy.

sshuttle/sshuttle@89c5b57

[untitaker]

I use setuptools_scm and readthedocs and am not seeing this behavior.

[brianmay]

@untitaker Can you please provide a link to your project? I am seeing this behaviour every time (without the work around).

[untitaker]

https://vdirsyncer.pimutils.org/en/master/ and https://vdirsyncer.pimutils.org/en/stable/ show the correct version each in the <title>, which is derived with pkg_resources in conf.py.

[brianmay]

@untitaker looks like your conf.py reads the version from vdirsyncer/version.py which is automatically generated by setuptools_scm, presumable before conf.py is altered by readthedocs:

release = vdirsyncer.__version__
version = '.'.join(release.split('.')[:2])  # The short X.Y version.

This is different (but maybe better???) then the recommended approach, from https://github.com/pypa/setuptools_scm, which asks setuptools_scm what the version number is when the documentation is being built.

Programmatic usage

In oder to use setuptools_scm for sphinx config

from setuptools_scm import get_version
version = get_version()

[alimanfoo]

I'm getting this problem for my project even though I get the version from the generated version.py file (here's my conf.py). Is there a workaround?

[brianmay]

@alimanfoo I mentioned my work around earlier in this issue: #2144 (comment)

See: sshuttle/sshuttle@89c5b57

[alimanfoo]

Great, thanks very much.

On Saturday, 23 July 2016, Brian May [email protected] wrote:

@alimanfoo https://github.com/alimanfoo I mentioned my work around
earlier in this issue: #2144 (comment)
#2144 (comment)

See: sshuttle/sshuttle@89c5b57
sshuttle/sshuttle@89c5b57

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2144 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq8Qi8EePJ-2x6-i1FCDgmETZ-EjYS-ks5qYe-fgaJpZM4IJU17
.

Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health http://cggh.org
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Email: [email protected] [email protected]
Web: http://purl.org/net/aliman
Twitter: https://twitter.com/alimanfoo
Tel: +44 (0)1865 287721

[agjohnson]

This issue has been open for a while, and I don't think we'll have the resources to address an edge case like this. If anyone else wants to take this on, I'm happy to assign, but closing for now.

[brianmay]

In any case there is documentation on how to avoid this problem: https://github.com/pypa/setuptools_scm#usage-from-sphinx

[humitos]

I just want to mention here we've documented a workaround for this issue at https://docs.readthedocs.io/en/latest/build-customization.html#avoid-having-a-dirty-git-index