Skip to content
This repository has been archived by the owner on Dec 9, 2024. It is now read-only.

Autover used in an installed package should "never be able to crash or hang" #64

Open
ceball opened this issue Apr 16, 2020 · 0 comments

Comments

@ceball
Copy link
Contributor

ceball commented Apr 16, 2020

I don't know if this is desirable in autover's design, or if it's possible, but I feel that autover should "never be able to crash or hang" for an installed package. I've used quotes because I'm not sure exactly what I mean :) I'm thinking how a regular __version__ string cannot possibly be the source of a crash or hang - so how close can autover get to that? Not running git on import would help (#58), but it would be worth carefully auditing the code path and assumptions a library using autover is making in producing its __version__ string.

Having said the above, it might already be fine: maybe only basic python stuff is happening, and anything else is guaranteed to never fail. Great! But I feel we should check and then could just happily close this issue if so.


And incidentally, at the opposite extreme, I think it might be useful if autover were guaranteed to fail (or at least clearly warn) during package building if version collection from git fails. It doesn't seem to, though I might be confused.

Maybe this is ok anyway, not sure? Maybe it has to be this way to support various "pip install from git" scenarios? Whatever, it's not worth spending a lot of time on - it's certainly nothing like as important to deal with as "problems at run time for users of installed packages". I just wanted to record my vague feelings about how things seem to be "the wrong way round" - i.e. sometimes failing at runtime for installed packages because of trying to get info from git before checking for .version, but not failing at package build time when the version can't be found from git and using .version instead.

Normal:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working tree clean
$ git describe --long --dirty
v0.2.5-7-g956ffe8
$ python setup.py sdist
running sdist
[...]
Writing autover-0.2.5.post7+g956ffe8/setup.cfg
creating dist
Creating tar archive
removing 'autover-0.2.5.post7+g956ffe8' (and everything under it)

Something wrong, e.g. no git - uses (stale) .version file if present (which it is, from command above)?

$ echo 'x' >> README.md 
$ git commit -m 'x' README.md 
[master 60deb7c] x
 1 file changed, 1 insertion(+)
$ git describe --long --dirty
v0.2.5-8-g60deb7c
$ sudo apt-get remove git
[...]
$ git
bash: /usr/bin/git: No such file or directory
$ python setup.py sdist
running sdist
[...]
Writing autover-0.2.5.post7+g956ffe8/setup.cfg
Creating tar archive
removing 'autover-0.2.5.post7+g956ffe8' (and everything under it)

Something wrong, e.g. no git - with no .version file present:

$ rm autover/.version 
$ python setup.py sdist
/home/sefkw/mc3/envs/miscdev37/lib/python3.7/site-packages/setuptools/dist.py:485: UserWarning: The version specified ('None') is an invalid version, this may not work as expected with newer versions of setuptools, pip, and PyPI. Please see PEP 440 for more details.
  "details." % self.metadata.version
running sdist
[...]
Writing autover-None/setup.cfg
Creating tar archive
removing 'autover-None' (and everything under it)

(At least here you can easily see it's failed to get an up to date version.)

("git missing" is supposed to be a proxy for some more likely scenario, but now I can't remember what that was supposed to be! Maybe there is no likely scenario :) )

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant