Page MenuHomePhabricator

Python environment weirdness on labs
Closed, InvalidPublic


Hey all, when debugging an issue with Weeklypedia ( /, I found an error in our error log on

Traceback (most recent call last):
  File "/data/project/weeklypedia/wp/", line 3, in <module>
    from weeklypedia.labs import wsgi_app
  File "/mnt/nfs/labstore-secondary-tools-project/weeklypedia/wp/weeklypedia/labs/", line 3, in <module>
    from web_api import wsgi_app
  File "/mnt/nfs/labstore-secondary-tools-project/weeklypedia/wp/weeklypedia/labs/", line 3, in <module>
    from dal import RecentChangesSummarizer
  File "/mnt/nfs/labstore-secondary-tools-project/weeklypedia/wp/weeklypedia/labs/", line 5, in <module>
    from datetime import datetime, timedelta
ImportError: No module named datetime

Not sure what would cause Python not to have a standard module like datetime, nor am I sure I got the right person assigned, but it would be good to get this fixed quickly.

Repro: access and look at /data/project/weeklypedia/logs/sv.txt on a tools machine.


Event Timeline

mahmoud created this task.Mar 31 2017, 5:06 PM
Restricted Application added a project: Cloud-Services. · View Herald TranscriptMar 31 2017, 5:06 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@mahmoud Webservices in tools need to be set up in a predetermined directory structure. You also don't need to define your own wsgi server, since the webservice abstraction already takes care of that. I went ahead and fixed yours up, and here are the steps: has docs for Python2 webservices. If you upgraded to Python3 - use kubernetes, docs here -

So far I,

  • copied contents of wp/ to www/python/src
  • created a venv in www/python/venv and installed dependencies from requirements.txt (+ oursql there) by activating venv (source $HOME/www/python/venv/bin/activate)
  • webservice uwsgi-python start
  • You can see uwsgi logs in uwsgi.log and check that it's running by doing qstat. is up now.

madhuvishy closed this task as Invalid.Mar 31 2017, 6:11 PM

Closing as invalid as the problem wasn't on the python environment end.

For future reference, this error is seen when a virtualenv is created on Precise and then used on Trusty (or vice versa), as the Python versions (or glibc versions, or... something else) don't match up anymore. The solution is re-creating the virtualenv.

@valhallasw Ah interesting, TIL - I suppose that may have been the real fix (I created a new venv) - thanks for the note :)

Ah, yes, I expected that the issue was related to the Ubuntu upgrade, I just didn't expect it to manifest as datetime being unimportable. I seem to recall the email saying a service restart was all that was necessary to upgrade, but things are never that easy :) I'll make a note to check the rest of our virtualenvs, too. Thank you everyone!