I think soon we'll put the Python 3 venv at `/srv/zulip-venv` and
make `/srv/zulip-py3-venv` just an alias to that (then remove the
alias too), but for now the old name is helpful for spotting places
that need an update.
The `/srv/zulip-venv` name still appears in codepaths used by Travis
tests.
I faced this problem many a times, might be of help to
beginners. Because, the same thing doesn't work when done through
`vagrant suspend` followed by `vagrant up`.
Aka the current "testing" release, expected to graduate to "stable"
later in 2017.
Fortunately the instructions are very similar to those for
Ubuntu 16.04 and 14.04 -- two packages don't exist, and
those two packages turn out (empirically, on my laptop)
not to be necessary.
Leave most references to "Ubuntu" still just saying "Ubuntu",
on the theory that Debian users will generally follow those
breadcrumbs where they lead and in order to keep lists short.
Before this commit, provisioning was done by executing provision.py,
which printed the log directly to stdout, making debugging harder.
This commit creates a wrapper bash script 'provision' in tools, which
calls 'zulip/scripts/tools/provision_vm.py' (the new location of
provision.py) and prints all the output to
'zulip/var/log/zulip/zulip_provision.log' via 'tee'.
Travis tests and docs have been modified accordingly.
Based on feedback from first-time contributors, this commit simplifies
the number of paths available for finding the dev setup directions you
need. Setup instructions are now organized into Recommended (Vagrant)
and Advanced (non-Vagrant).
In order to get the ToC to display correctly, I've combined all the
advanced, non-Vagrant methods into one page. I've left the old pages
intact, with a note that the content has been moved and link to the new
page. This is in case folks have linked directly to those pages.
The advanced setup directions still need to be cleaned up, but this is a
start.
Two reasons not to use such links:
- when making doc changes, if you follow links in your local build, they can
cause you to silently end up no longer reading your local changes
- they can cause you to randomly switch between http:// and https://
This adds support for using VMWare Fusion as the Vagrant provider,
which has better performance than Virtualbox at the price of being
nonfree (in all senses of the term).
We haven't done solid benchmarking as to how much faster it is than
the Virtualbox provider.