Under Python 2 we got away with having the ./update script be a locally callable script. Under Python 3 this hits issues due to the inclusion of the script's own directory on the sys.path which is looked at for imports.
Oddly, the stacktrace we get on failure suggests that modules from sr.comp.http actually are found from the global set, however those outside that namespace are the ones which fail:
Traceback (most recent call last):
File "/home/srcomp/srcomp-http/update", line 5, in <module>
from sr.comp.http import update
File "/usr/local/lib/python3.5/dist-packages/sr/comp/http/__init__.py", line 1, in <module>
from .server import app
File "/usr/local/lib/python3.5/dist-packages/sr/comp/http/server.py", line 11, in <module>
from sr.comp.match_period import MatchType
ImportError: No module named 'sr.comp.match_period'
Turns out that python -m sr.comp.http.update was already supported. As that's good enough for the intended use-cases we don't need to also install a specific entry point (which I had thought we would need to).
Under Python 2 we got away with having the
./update
script be a locally callable script. Under Python 3 this hits issues due to the inclusion of the script's own directory on thesys.path
which is looked at for imports.For example:
Oddly, the stacktrace we get on failure suggests that modules from
sr.comp.http
actually are found from the global set, however those outside that namespace are the ones which fail: