Prevent autover from failing when used alongside async frameworks#59
Prevent autover from failing when used alongside async frameworks#59julioasotodv wants to merge 4 commits into
Conversation
Looks like the travis build of master has been failing since around late 2018 :( |
|
@jlstevens is looking into it. |
|
@jlstevens, looks like the test that's failing (for "depends on autover" tests) fails because of one or more changes to pip over time, meaning something about how the project is set up is no longer correct. |
|
Now it's failing at downloading miniconda. Edit: Hmm. autover is using a very old version of pyctdev, from when it was still called pyct. And pyct(dev) hardcodes the miniconda url. And the miniconda download url has changed from continuum to anaconda. |
|
@julioasotodv The existing tests are now fixed, so you could rebase/merge/whatever. Plus a test for your change, if easy. But if you do want to add a test, note that the test framework is a bit tricky, for multiple reasons; if you can suggest a simple test to reproduce the failure you are fixing, I might be able to say how/where to add it. |
|
Hi @ceball I believe tests are still broken, given that this commit: f97d80b Makes the linter step in Travis complain: https://travis-ci.org/github/pyviz-dev/autover/jobs/674887606 |
|
This is showing the "bundled" example/test of autover has not been updated. We check autover works in various installation/usage scenarios, and that's one of them. So looks like you have to make changes twice... |
|
Actually, looks like there are two "bundle examples" - so three places to update in total! I guess the second bundle example is because at some point we discovered a problem with repository name being different from package name, or something like that. I'm sure we could do better than requiring developers to update three files to get all the tests to pass, but it's a low traffic project... (Sorry for the giant screenshot - on my phone!) |
|
@ceball no, it’s fine; don’t worry. I’ll try again in a couple of minutes |
|
Finally! |
|
Is there a way we can easily test this change, to make sure it does not recur? I.e. how do we trigger the problem in the first place? If you were to paste:
then I could probably add it as a test. It would be great if you could open an issue on this repository with the above info - I've lost track of where the original report was (I'm sure there was one with more detail at some point...)! Having said all that, I don't think it's necessary, in that I would merge the change here anyway (but @jlstevens will be the one to say what to do). |
|
@ceball I added a new unit test in the PR. Basically, when autover is used in a Python process created by os.fork() (just like Gunicorn does, for instance), the |
| source_files: | ||
| - tests | ||
| commands: | ||
| - conda install -y -c conda-forge gunicorn uvicorn starlette |
There was a problem hiding this comment.
It should be possible to declare these dependencies rather than running a command explicitly: https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#test-requirements
There was a problem hiding this comment.
Yes, I first thought about that. Unfortunately, apparently the test requirements cannot refer to a library that is not in the same conda channel as the project; and given that uvicorn is not available in the channel, it had no way of satisfying the requirement unless I explicitly conda installed it.
There was a problem hiding this comment.
Ha ha, you can't win, sorry. No need to change then.
@jbednar @jlstevens can I change this project to use conda-forge?
|
|
||
| print(autover.__version__) | ||
|
|
||
| app = Starlette() |
There was a problem hiding this comment.
Is this file a "test support file" rather than an actual test? If so, maybe rename it so it's clearly not a file containing tests, and then no need to exclude specially from nose? (Unless there's some reason that's not possible?)
There was a problem hiding this comment.
I did it that way just to make sure that the file got bundled when creating the package (as everything that is named test* inside the tests folder does), but I can just modify setup.py to force the file inclusion there after renaming. I don't know which one is more elegant...
There was a problem hiding this comment.
as everything that is named test* inside the tests folder does
Do you happen to know if that is a limitation we have put in somewhere here in autover? I wasn't aware of this as a general thing (in setup tools, tox, etc), and I'm only on my phone just now...
There was a problem hiding this comment.
Without your fix, the test you added results in an exception? And with the fix, it results in the test passing - but could you add an assertion about what the value of __version__ is when it does pass? (I still don't understand what is being returned by autover for the version in this scenario, although I believe it's something like "None"? That seems wrong to me, but hugely preferable to the current situation, i.e. a crash...)
|
Thanks for all that work! I am impressed you figured out how to modify autover's code, how to contribute to autover plus its tests, and stuck with that process through the delays etc!
autover in one sentence, ha ha! But seriously, I believe the work you have done is important. autover causes various problems in real-world environments, and if we don't eliminate them, it's at best just embarrassing for projects like param, panel, holoviews, etc ("You want me to add a package to my production environment that runs git (multiple times!) every time a user imports it? Now why would I want to add a package that does stuff like that?"...). |
Indeed, the spawned process (for instance by Gunicorn) just chrashes with the following exception (without the fix): File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/panel/__init__.py", line 5, in <module>
from . import layout # noqa
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/panel/layout.py", line 21, in <module>
from .io.model import hold
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/panel/io/__init__.py", line 6, in <module>
from .embed import embed_state # noqa
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/panel/io/embed.py", line 21, in <module>
from .model import add_to_doc, diff
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/panel/io/model.py", line 14, in <module>
from .state import state
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/panel/io/state.py", line 14, in <module>
from pyviz_comms import CommManager as _CommManager
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/pyviz_comms/__init__.py", line 14, in <module>
reponame="pyviz_comms"))
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/param/version.py", line 278, in __str__
known_stale = self._known_stale()
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/param/version.py", line 223, in _known_stale
commit = self.commit
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/param/version.py", line 133, in commit
return self.fetch()._commit
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/param/version.py", line 162, in fetch
self.git_fetch(cmd)
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/param/version.py", line 212, in git_fetch
self._update_from_vcs(output)
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/param/version.py", line 258, in _update_from_vcs
self._release = tuple(int(el) for el in dot_split)
File "/home/julio/anaconda3/envs/bokeh_starlette_server/lib/python3.7/site-packages/param/version.py", line 258, in <genexpr>
self._release = tuple(int(el) for el in dot_split)
ValueError: invalid literal for int() with base 10: ''That's why in the tests we record what the spawned process logs, and we ensure its stderr is empty. |
|
But what is the value of |
|
It looks like you print it, but I can't find the test in the travis job logs - at least, not on my phone 😂 |
So, the issue came back from https://github.com/holoviz/param. Some other holoviz projects (such as HoloViews and Panel) make use of So basically the issue prevents me from using HoloViews/Panel in a async (asgi) web application, since the version generated attribute for those libraries was generated at runtime, and the runtime crashed. Since As for why my test decides to print version, it is just a way to force its generation. It could very well be: _ = autover.__version__ |
|
I'm only asking, what does it end up being set to in this scenario, after your fix? I realize it won't be the correct version, but what is it? I'd like to put something like this in: I.e. I'm not asking for any more changes to the code, just to record what the situation is in the tests. Does it make sense? Sorry for not being clear! |
|
I now found the new test running on travis (I'm on a computer now :) ), but unfortunately the print is swallowed so I can't see for myself what https://travis-ci.org/github/pyviz-dev/autover/jobs/675250008#L243 |
No problem, it was just to give you some context. The problem won't be that However, I will try to document the test and |
|
Sorry, we are misunderstanding each other here. I am asking you to say what the value of |
|
If you also have no idea what it is after your fix, no problem. (I just assumed you would know, because you have been running it.) |
|
I got your PR and tried it on my own machine. If I run your test without your Anyway, early on, I asked for a few bits of info:
You have supplied the first one (the code fragment) - thanks! I still need an answer to the second one (i.e. when do you get the problem? e.g. you pip install panel from pypi, and then when you use panel in your app, you get the crash?). The third one (what happens without your fix?), I see you previously answered in a comment on your original pyviz_comms issue (thanks!). The fourth one I can find out for myself if you answer the second one, above. I can then move your test to the appropriate place, so that it has the right environment to trigger the problem in the first place. It's also possible that I could convert your test into a simpler case that will work in a unit test, but I don't want to think about that until I can first actually reproduce your problem. Thanks! |
| with open(logfile_path, "r") as gunicorn_log_file: | ||
| stderr_log = gunicorn_log_file.read() | ||
|
|
||
| subprocess.Popen(["pkill", "-f", "gunicorn"]) |
There was a problem hiding this comment.
I guess it would be better to kill exactly the pid that was created, in case there are other things running. But we might be able to create an entirely simpler test (we'll see once I can reproduce), so let's wait and see.
There was a problem hiding this comment.
Yeah, I guess you are right. Fortunately, Gunicorn can output the PID that launches, so can be retreived by Python and be killed.
Exactly. The error happened either:
You can try it for instance if you temporarily add something like With that said, when installed as package (with the patch), the |
|
The changes to |
|
In #67 the |
5 participants
Basically the same PR as the one I did in param.version: holoviz/param#389
However, according to @ceball autover has tests for that part of param, so we can test it here.
Fixes #62