This causes `upgrade-zulip-from-git`, as well as a no-option run of
`tools/build-release-tarball`, to produce a Zulip install running
Python 3, rather than Python 2. In particular this means that the
virtualenv we create, in which all application code runs, is Python 3.
One shebang line, on `zulip-ec2-configure-interfaces`, explicitly
keeps Python 2, and at least one external ops script, `wal-e`, also
still runs on Python 2. See discussion on the respective previous
commits that made those explicit. There may also be some other
third-party scripts we use, outside of this source tree and running
outside our virtualenv, that still run on Python 2.
Django, by default, prints these exceptions as a giant traceback,
which is really ugly and scary to sysadmins. We really just want to
print the error message to stdout for convenient viewing by the user.
The manage.py change effectively switches the Zulip production server
to use the virtualenv, since all of our supervisord commands for the
various Python services go through manage.py.
Additionally, this migrates the production scripts and Nagios plugins
to use the virtualenv as well.
This automatically loads settings, zerver.models.* and
zerver.lib.actions.* when you start `manage.py shell`, which should
save a bit of time basically every time someone uses it.
Fixes#275.
This could potentially help with debugging exactly what happened with
some issue down the line.
(imported from commit cc7321d742875b644d4727a084b462dcd01dcf10)
This includes a hack to preserve humbug/backends.py as a symlink, so
that we don't need to regenerate all our old sessions.
(imported from commit b7918988b31c71ec01bbdc270db7017d4069221d)
I first made --traceback the default in my patches to django, but this
broke several regressions tests (when Luke built .deb packages), so he reverted that change,
and I'm putting this default into our manage.py instead
(imported from commit 460253561e637d8a6692c68bbd3859f266dbf83d)