Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/tools/setup/setup_venvs.py

27 lines
886 B
Python
Raw Normal View History

py3: Switch almost all shebang lines to use `python3`. 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.
2017-08-02 23:15:16 +02:00
#!/usr/bin/env python3
Factor out venv-installing code into a module. Factor out the code in tools/provision.py which installs a python2 and python3 venv into a module (tools/setup/setup_venvs.py) which can also be used as a script.
2016-07-21 01:56:50 +02:00
import os
import sys
python: Add lint rule banning 'from os.path import'. This enforces our use of a consistent style in how we access Python modules; "from os.path import dirname" is a particularly popular abbreviation inconsistent with our style, and so it deserves a lint rule. Commit message and error text tweaked by tabbott. Fixes #6543.
2017-09-22 08:15:01 +02:00
ZULIP_PATH = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
Factor out venv-installing code into a module. Factor out the code in tools/provision.py which installs a python2 and python3 venv into a module (tools/setup/setup_venvs.py) which can also be used as a script.
2016-07-21 01:56:50 +02:00
if ZULIP_PATH not in sys.path:
sys.path.append(ZULIP_PATH)
from scripts.lib.setup_venv import setup_virtualenv
setup_venv: Link to the correct Python interpreter. Travis enables different Python versions through virtual environments, but it seems that there is a little caveat when we try to create Zulip's virtual environment by referring Travis' virtual environment; Zulip's virtual environment refers the system Python. We encountered this behaviour when we tried to run our backend test suite under Python 3.5 in Travis. 'python3 --version' command before activating Zulip's virtualenv showed 'Python 3.5.3' and after it showed 'Python 3.4.3'. This happened when we created the virtual environment using 'virtualenv -p python3'. The solution seems to be to explicitly give the path of the Python interpreter in the Travis' virtual environment using 'which python3'.
2017-09-01 06:27:30 +02:00
from scripts.lib.zulip_tools import run, subprocess_text_output
Factor out venv-installing code into a module. Factor out the code in tools/provision.py which installs a python2 and python3 venv into a module (tools/setup/setup_venvs.py) which can also be used as a script.
2016-07-21 01:56:50 +02:00
py3: Cut Python 2 codepaths from provision.
2017-08-09 00:38:30 +02:00
VENV_PATH = "/srv/zulip-py3-venv"
Ensure virtualenv is run throughout the entire Travis dev provision.
2017-06-17 15:14:59 +02:00
requirements: Rename requirements files. This commit renames various source requirements files like `dev.txt`, `mypy.txt` etc to `dev.in`, `mypy.in` etc and various locked requirements files like `dev_lock.txt`, `mypy_lock.txt` etc to `dev.txt`, `mypy.txt` etc. This will help in emphasizing to the user that *.in are actually input to `update-locked-requirements` tool which should be run after updating any of these.
2017-11-17 02:41:06 +01:00
DEV_REQS_FILE = os.path.join(ZULIP_PATH, "requirements", "dev.txt")
Ensure virtualenv is run throughout the entire Travis dev provision.
2017-06-17 15:14:59 +02:00
provision: Remove transitional Python 2->3 logic in setup_venvs. At this point if we were accidentally using `/srv/zulip-venv` for anything, we'd have run into it by now. So just drop the bit of historical logic that we had to ensure that.
2017-12-19 06:49:51 +01:00
def main() -> None:
setup_venv: Link to the correct Python interpreter. Travis enables different Python versions through virtual environments, but it seems that there is a little caveat when we try to create Zulip's virtual environment by referring Travis' virtual environment; Zulip's virtual environment refers the system Python. We encountered this behaviour when we tried to run our backend test suite under Python 3.5 in Travis. 'python3 --version' command before activating Zulip's virtualenv showed 'Python 3.5.3' and after it showed 'Python 3.4.3'. This happened when we created the virtual environment using 'virtualenv -p python3'. The solution seems to be to explicitly give the path of the Python interpreter in the Travis' virtual environment using 'which python3'.
2017-09-01 06:27:30 +02:00
# Get the correct Python interpreter. If we don't do this and use
# `virtualenv -p python3` to create the venv in Travis, the venv
# starts referring to the system Python interpreter.
python_interpreter = subprocess_text_output(['which', 'python3'])
provision: Remove transitional Python 2->3 logic in setup_venvs. At this point if we were accidentally using `/srv/zulip-venv` for anything, we'd have run into it by now. So just drop the bit of historical logic that we had to ensure that.
2017-12-19 06:49:51 +01:00
setup_virtualenv(VENV_PATH, DEV_REQS_FILE, patch_activate_script=True,
virtualenv_args=['-p', python_interpreter])
Factor out venv-installing code into a module. Factor out the code in tools/provision.py which installs a python2 and python3 venv into a module (tools/setup/setup_venvs.py) which can also be used as a script.
2016-07-21 01:56:50 +02:00
if __name__ == "__main__":
main()