packagename.__version__ has wrong git info when run in git repository

[kbarbary]

To reproduce, cd into any git repository and import a different astropy affiliated package. If the affiliated package is on a development version, packagename.__version__ will be "MAJOR.MINOR.devNUM" where "NUM" is wrong: it is the number of commits in the current git repository rather than that of packagename.

[embray]

I can confirm this just by looking at the code--the generated version.py calls update_git_devstr the the default path argument, which uses os.getcwd() by default. It should instead look somewhere relative to the version.py file.

One problem is that the code looks in the path for a .git file (in order to skip the overhead of trying to call the git command when not in a git repository). However, if the default path is to be relative to some file in the source tree, there needs to be some way of reliably finding the root of the source. Just walking up directories until a .git file is located is not always good enough. In astropy/astropy#3085 I got around this by adding an .astropy-root file to the source tree that would allow it to be found unambiguously. But I'm not completely crazy about that either, and it doesn't generalize well to other projects. Any ideas for this?

[embray]

I suppose it's safe to search up for a .git as long as it can be guaranteed that the python package directory starts at the root of the source tree (as opposed tolib/<packagename or something like that).

[embray]

Oh duh-- .git and setup.py would be a perfectly good heursitic :) For a Python project anyways.

[kbarbary]

Didn't it used to be that the generated version.py just had the full version string and didn't try to update it upon import? (I haven't followed the development on this very closely.)

[astrofrog]

Just to add a datapoint - I actually use git for all my projects and sometimes create scripts called setup.py, so just the presence of .git and setup.py is not safe (though the presence of .git and setup.py in a parent directory of version.py is probably fine).

Anyway, shouldn't this just be determined at build time and encoded in version.py as @kbarbary is suggesting?

[astrofrog]

Related issue: https://github.com/astropy/astropy/issues/2561

[embray]

I actually use git for all my projects and sometimes create scripts called setup.py

But would you under any circumstances have the Astropy source code (or any other source code with an astropy-helpers version.py just sitting in there?

[embray]

I can't remember, but that's probably a fair point. There's no reason an installed version should have to be able to update anything.

[embray]

In fact I think I did add the capability to generate a totally "static" version.py, it looks like it just isn't used anywhere. Last I remember that used to work, as @kbarbary said. So maybe there was a regression somewhere.

[astrofrog]

@embray - regarding your question about having the astropy source there - no.

[embray]

Should be fixed by #137.