You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 9, 2024. It is now read-only.
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 :) )
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
Something wrong, e.g. no git - uses (stale)
.version
file if present (which it is, from command above)?Something wrong, e.g. no git - with no
.version
file present:(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 :) )
The text was updated successfully, but these errors were encountered: