2018-11-07 20:16:16 -05:00
|
|
|
#!/usr/bin/env python
|
2018-11-19 14:47:14 -05:00
|
|
|
"""Aids in creating a developer virtual environment for Certbot.
|
|
|
|
|
|
|
|
|
|
When this module is run as a script, it takes the arguments that should
|
|
|
|
|
be passed to pip to install the Certbot packages as command line
|
|
|
|
|
arguments. The virtual environment will be created with the name "venv"
|
|
|
|
|
in the current working directory and will use the default version of
|
|
|
|
|
Python for the virtualenv executable in your PATH. You can change the
|
|
|
|
|
name of the virtual environment by setting the environment variable
|
|
|
|
|
VENV_NAME.
|
|
|
|
|
"""
|
2018-11-07 20:16:16 -05:00
|
|
|
|
|
|
|
|
from __future__ import print_function
|
|
|
|
|
|
2020-06-01 18:18:38 -04:00
|
|
|
from distutils.version import LooseVersion
|
2019-12-09 15:50:20 -05:00
|
|
|
import glob
|
2018-11-07 20:16:16 -05:00
|
|
|
import os
|
2019-12-09 15:50:20 -05:00
|
|
|
import re
|
2018-11-07 20:16:16 -05:00
|
|
|
import shutil
|
|
|
|
|
import subprocess
|
|
|
|
|
import sys
|
2019-12-09 15:50:20 -05:00
|
|
|
import time
|
2019-04-05 18:01:09 -04:00
|
|
|
|
|
|
|
|
REQUIREMENTS = [
|
|
|
|
|
'-e acme[dev]',
|
Refactor certbot/ and certbot/tests/ to use the same structure as the other packages (#7544)
Summary of changes in this PR:
- Refactor files involved in the `certbot` module to be of a similar structure to every other package; that is, inside a directory inside the main repo root (see below).
- Make repo root README symlink to `certbot` README.
- Pull tests outside of the distributed module.
- Make `certbot/tests` not be a module so that `certbot` isn't added to Python's path for module discovery.
- Remove `--pyargs` from test calls, and make sure to call tests from repo root since without `--pyargs`, `pytest` takes directory names rather than package names as arguments.
- Replace mentions of `.` with `certbot` when referring to packages to install, usually editably.
- Clean up some unused code around executing tests in a different directory.
- Create public shim around main and make that the entry point.
New directory structure summary:
```
repo root ("certbot", probably, but for clarity all files I mention are relative to here)
├── certbot
│ ├── setup.py
│ ├── certbot
│ │ ├── __init__.py
│ │ ├── achallenges.py
│ │ ├── _internal
│ │ │ ├── __init__.py
│ │ │ ├── account.py
│ │ │ ├── ...
│ │ ├── ...
│ ├── tests
│ │ ├── account_test.py
│ │ ├── display
│ │ │ ├── __init__.py
│ │ │ ├── ...
│ │ ├── ... # note no __init__.py at this level
│ ├── ...
├── acme
│ ├── ...
├── certbot-apache
│ ├── ...
├── ...
```
* refactor certbot/ and certbot/tests/ to use the same structure as the other packages
* git grep -lE "\-e(\s+)\." | xargs sed -i -E "s/\-e(\s+)\./-e certbot/g"
* git grep -lE "\.\[dev\]" | xargs sed -i -E "s/\.\[dev\]/certbot[dev]/g"
* git grep -lE "\.\[dev3\]" | xargs sed -i -E "s/\.\[dev3\]/certbot[dev3]/g"
* Remove replacement of certbot into . in install_and_test.py
* copy license back out to main folder
* remove linter_plugin.py and CONTRIBUTING.md from certbot/MANIFEST.in because these files are not under certbot/
* Move README back into main folder, and make the version inside certbot/ a symlink
* symlink certbot READMEs the other way around
* move testdata into the public api certbot zone
* update source_paths in tox.ini to certbot/certbot to find the right subfolder for tests
* certbot version has been bumped down a directory level
* make certbot tests directory not a package and import sibling as module
* Remove unused script cruft
* change . to certbot in test_sdists
* remove outdated comment referencing a command that doesn't work
* Install instructions should reference an existing file
* update file paths in Dockerfile
* some package named in tox.ini were manually specified, change those to certbot
* new directory format doesn't work easily with pyargs according to http://doc.pytest.org/en/latest/goodpractices.html#tests-as-part-of-application-code
* remove other instance of pyargs
* fix up some references in _release.sh by searching for ' . ' and manual check
* another stray . in tox.ini
* fix paths in tools/_release.sh
* Remove final --pyargs call, and now-unnecessary call to modules instead of local files, since that's fixed by certbot's code being one layer deeper
* Create public shim around main and make that the entry point
* without pyargs, tests cannot be run from an empty directory
* Remove cruft for running certbot directly from main
* Have main shim take real arg
* add docs/api file for main, and fix up main comment
* Update certbot/docs/install.rst
Co-Authored-By: Brad Warren <bmw@users.noreply.github.com>
* Fix comments in readthedocs requirements files to refer to current package
* Update .[docs] reference in contributing.rst
* Move plugins tests to certbot tests directory
* add certbot tests to MANIFEST.in so packagers can run python setup.py test
* move examples directory inside certbot/
* Move CHANGELOG into certbot, and create a top-level symlink
* Remove unused sys and logging from main shim
* nginx http01 test no longer relies on certbot plugins common test
2019-11-25 17:28:06 -05:00
|
|
|
'-e certbot[dev,docs]',
|
2019-04-05 18:01:09 -04:00
|
|
|
'-e certbot-apache',
|
|
|
|
|
'-e certbot-dns-cloudflare',
|
|
|
|
|
'-e certbot-dns-cloudxns',
|
|
|
|
|
'-e certbot-dns-digitalocean',
|
|
|
|
|
'-e certbot-dns-dnsimple',
|
|
|
|
|
'-e certbot-dns-dnsmadeeasy',
|
|
|
|
|
'-e certbot-dns-gehirn',
|
|
|
|
|
'-e certbot-dns-google',
|
|
|
|
|
'-e certbot-dns-linode',
|
|
|
|
|
'-e certbot-dns-luadns',
|
|
|
|
|
'-e certbot-dns-nsone',
|
|
|
|
|
'-e certbot-dns-ovh',
|
|
|
|
|
'-e certbot-dns-rfc2136',
|
|
|
|
|
'-e certbot-dns-route53',
|
|
|
|
|
'-e certbot-dns-sakuracloud',
|
|
|
|
|
'-e certbot-nginx',
|
|
|
|
|
'-e certbot-compatibility-test',
|
2019-05-14 16:56:32 -04:00
|
|
|
'-e certbot-ci',
|
2019-04-05 18:01:09 -04:00
|
|
|
]
|
Update tools/venv3.py to support py launcher on Windows (#6493)
Following some inconsistencies occurred during by developments, and in the light of #6508, it decided to wrote a PR that will take fully advantage of the conversion from bash to python to the development setup tools.
This PR adresses several issues when trying to use the development setup tools (`tools/venv.py` and `tools/venv3.py`:
* on Windows, `python` executable is not always in PATH (default behavior)
* even if the option is checked, the `python` executable is not associated to the usually symlink `python3` on Windows
* on Windows again, really powerful introspection of the available Python environments can be done with `py`, the Windows Python launcher
* in general for all systems, `tools/venv.py` and `tools/venv3.py` ensures that the respective Python major version will be used to setup the virtual environment if available.
* finally, the best and first candidate to test should be the Python executable used to launch the `tools/venv*.py` script. It was not relevant before because it was shell scripts, but do it is.
The logic is shared in `_venv_common.py`, and will be called appropriately for both scripts. In priority decreasing order, python executable will be search and tested:
* from the current Python executable, as exposed by `sys.executable`
* from any python or pythonX (X as a python version like 2, 3 or 2.7 or 3.4) executable available in PATH
* from the Windows Python launched `py` if available
Individual changes were:
* Update tools/venv3.py to support py launcher on Windows
* Fix typo in help message
* More explicit calls with space protection
* Complete refactoring to take advantage of the python runtime, and control of the compatible version to use.
2018-11-15 18:17:36 -05:00
|
|
|
|
|
|
|
|
VERSION_PATTERN = re.compile(r'^(\d+)\.(\d+).*$')
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class PythonExecutableNotFoundError(Exception):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def find_python_executable(python_major):
|
|
|
|
|
# type: (int) -> str
|
|
|
|
|
"""
|
|
|
|
|
Find the relevant python executable that is of the given python major version.
|
|
|
|
|
Will test, in decreasing priority order:
|
2020-08-16 16:19:08 -04:00
|
|
|
|
Update tools/venv3.py to support py launcher on Windows (#6493)
Following some inconsistencies occurred during by developments, and in the light of #6508, it decided to wrote a PR that will take fully advantage of the conversion from bash to python to the development setup tools.
This PR adresses several issues when trying to use the development setup tools (`tools/venv.py` and `tools/venv3.py`:
* on Windows, `python` executable is not always in PATH (default behavior)
* even if the option is checked, the `python` executable is not associated to the usually symlink `python3` on Windows
* on Windows again, really powerful introspection of the available Python environments can be done with `py`, the Windows Python launcher
* in general for all systems, `tools/venv.py` and `tools/venv3.py` ensures that the respective Python major version will be used to setup the virtual environment if available.
* finally, the best and first candidate to test should be the Python executable used to launch the `tools/venv*.py` script. It was not relevant before because it was shell scripts, but do it is.
The logic is shared in `_venv_common.py`, and will be called appropriately for both scripts. In priority decreasing order, python executable will be search and tested:
* from the current Python executable, as exposed by `sys.executable`
* from any python or pythonX (X as a python version like 2, 3 or 2.7 or 3.4) executable available in PATH
* from the Windows Python launched `py` if available
Individual changes were:
* Update tools/venv3.py to support py launcher on Windows
* Fix typo in help message
* More explicit calls with space protection
* Complete refactoring to take advantage of the python runtime, and control of the compatible version to use.
2018-11-15 18:17:36 -05:00
|
|
|
* the current Python interpreter
|
|
|
|
|
* 'pythonX' executable in PATH (with X the given major version) if available
|
|
|
|
|
* 'python' executable in PATH if available
|
|
|
|
|
* Windows Python launcher 'py' executable in PATH if available
|
2020-08-16 16:19:08 -04:00
|
|
|
|
|
|
|
|
Incompatible python versions for Certbot will be evicted (e.g. Python 3
|
|
|
|
|
versions less than 3.6).
|
|
|
|
|
|
Update tools/venv3.py to support py launcher on Windows (#6493)
Following some inconsistencies occurred during by developments, and in the light of #6508, it decided to wrote a PR that will take fully advantage of the conversion from bash to python to the development setup tools.
This PR adresses several issues when trying to use the development setup tools (`tools/venv.py` and `tools/venv3.py`:
* on Windows, `python` executable is not always in PATH (default behavior)
* even if the option is checked, the `python` executable is not associated to the usually symlink `python3` on Windows
* on Windows again, really powerful introspection of the available Python environments can be done with `py`, the Windows Python launcher
* in general for all systems, `tools/venv.py` and `tools/venv3.py` ensures that the respective Python major version will be used to setup the virtual environment if available.
* finally, the best and first candidate to test should be the Python executable used to launch the `tools/venv*.py` script. It was not relevant before because it was shell scripts, but do it is.
The logic is shared in `_venv_common.py`, and will be called appropriately for both scripts. In priority decreasing order, python executable will be search and tested:
* from the current Python executable, as exposed by `sys.executable`
* from any python or pythonX (X as a python version like 2, 3 or 2.7 or 3.4) executable available in PATH
* from the Windows Python launched `py` if available
Individual changes were:
* Update tools/venv3.py to support py launcher on Windows
* Fix typo in help message
* More explicit calls with space protection
* Complete refactoring to take advantage of the python runtime, and control of the compatible version to use.
2018-11-15 18:17:36 -05:00
|
|
|
:param int python_major: the Python major version to target (2 or 3)
|
|
|
|
|
:rtype: str
|
|
|
|
|
:return: the relevant python executable path
|
|
|
|
|
:raise RuntimeError: if no relevant python executable path could be found
|
|
|
|
|
"""
|
|
|
|
|
python_executable_path = None
|
|
|
|
|
|
|
|
|
|
# First try, current python executable
|
|
|
|
|
if _check_version('{0}.{1}.{2}'.format(
|
|
|
|
|
sys.version_info[0], sys.version_info[1], sys.version_info[2]), python_major):
|
|
|
|
|
return sys.executable
|
|
|
|
|
|
|
|
|
|
# Second try, with python executables in path
|
|
|
|
|
versions_to_test = ['2.7', '2', ''] if python_major == 2 else ['3', '']
|
|
|
|
|
for one_version in versions_to_test:
|
|
|
|
|
try:
|
|
|
|
|
one_python = 'python{0}'.format(one_version)
|
|
|
|
|
output = subprocess.check_output([one_python, '--version'],
|
|
|
|
|
universal_newlines=True, stderr=subprocess.STDOUT)
|
|
|
|
|
if _check_version(output.strip().split()[1], python_major):
|
|
|
|
|
return subprocess.check_output([one_python, '-c',
|
|
|
|
|
'import sys; sys.stdout.write(sys.executable);'],
|
|
|
|
|
universal_newlines=True)
|
|
|
|
|
except (subprocess.CalledProcessError, OSError):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
# Last try, with Windows Python launcher
|
|
|
|
|
try:
|
|
|
|
|
env_arg = '-{0}'.format(python_major)
|
|
|
|
|
output_version = subprocess.check_output(['py', env_arg, '--version'],
|
|
|
|
|
universal_newlines=True, stderr=subprocess.STDOUT)
|
|
|
|
|
if _check_version(output_version.strip().split()[1], python_major):
|
|
|
|
|
return subprocess.check_output(['py', env_arg, '-c',
|
|
|
|
|
'import sys; sys.stdout.write(sys.executable);'],
|
|
|
|
|
universal_newlines=True)
|
|
|
|
|
except (subprocess.CalledProcessError, OSError):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
if not python_executable_path:
|
|
|
|
|
raise RuntimeError('Error, no compatible Python {0} executable for Certbot could be found.'
|
|
|
|
|
.format(python_major))
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def _check_version(version_str, major_version):
|
|
|
|
|
search = VERSION_PATTERN.search(version_str)
|
|
|
|
|
|
|
|
|
|
if not search:
|
|
|
|
|
return False
|
|
|
|
|
|
|
|
|
|
version = (int(search.group(1)), int(search.group(2)))
|
|
|
|
|
|
|
|
|
|
minimal_version_supported = (2, 7)
|
2020-08-16 16:19:08 -04:00
|
|
|
if major_version == 3:
|
|
|
|
|
minimal_version_supported = (3, 6)
|
Update tools/venv3.py to support py launcher on Windows (#6493)
Following some inconsistencies occurred during by developments, and in the light of #6508, it decided to wrote a PR that will take fully advantage of the conversion from bash to python to the development setup tools.
This PR adresses several issues when trying to use the development setup tools (`tools/venv.py` and `tools/venv3.py`:
* on Windows, `python` executable is not always in PATH (default behavior)
* even if the option is checked, the `python` executable is not associated to the usually symlink `python3` on Windows
* on Windows again, really powerful introspection of the available Python environments can be done with `py`, the Windows Python launcher
* in general for all systems, `tools/venv.py` and `tools/venv3.py` ensures that the respective Python major version will be used to setup the virtual environment if available.
* finally, the best and first candidate to test should be the Python executable used to launch the `tools/venv*.py` script. It was not relevant before because it was shell scripts, but do it is.
The logic is shared in `_venv_common.py`, and will be called appropriately for both scripts. In priority decreasing order, python executable will be search and tested:
* from the current Python executable, as exposed by `sys.executable`
* from any python or pythonX (X as a python version like 2, 3 or 2.7 or 3.4) executable available in PATH
* from the Windows Python launched `py` if available
Individual changes were:
* Update tools/venv3.py to support py launcher on Windows
* Fix typo in help message
* More explicit calls with space protection
* Complete refactoring to take advantage of the python runtime, and control of the compatible version to use.
2018-11-15 18:17:36 -05:00
|
|
|
|
|
|
|
|
if version >= minimal_version_supported:
|
|
|
|
|
return True
|
|
|
|
|
|
|
|
|
|
print('Incompatible python version for Certbot found: {0}'.format(version_str))
|
|
|
|
|
return False
|
|
|
|
|
|
2018-11-07 20:16:16 -05:00
|
|
|
|
2020-04-13 13:41:39 -04:00
|
|
|
def subprocess_with_print(cmd, env=None, shell=False):
|
|
|
|
|
if env is None:
|
|
|
|
|
env = os.environ
|
2018-11-19 18:38:37 -05:00
|
|
|
print('+ {0}'.format(subprocess.list2cmdline(cmd)) if isinstance(cmd, list) else cmd)
|
|
|
|
|
subprocess.check_call(cmd, env=env, shell=shell)
|
2018-11-07 20:16:16 -05:00
|
|
|
|
Update tools/venv3.py to support py launcher on Windows (#6493)
Following some inconsistencies occurred during by developments, and in the light of #6508, it decided to wrote a PR that will take fully advantage of the conversion from bash to python to the development setup tools.
This PR adresses several issues when trying to use the development setup tools (`tools/venv.py` and `tools/venv3.py`:
* on Windows, `python` executable is not always in PATH (default behavior)
* even if the option is checked, the `python` executable is not associated to the usually symlink `python3` on Windows
* on Windows again, really powerful introspection of the available Python environments can be done with `py`, the Windows Python launcher
* in general for all systems, `tools/venv.py` and `tools/venv3.py` ensures that the respective Python major version will be used to setup the virtual environment if available.
* finally, the best and first candidate to test should be the Python executable used to launch the `tools/venv*.py` script. It was not relevant before because it was shell scripts, but do it is.
The logic is shared in `_venv_common.py`, and will be called appropriately for both scripts. In priority decreasing order, python executable will be search and tested:
* from the current Python executable, as exposed by `sys.executable`
* from any python or pythonX (X as a python version like 2, 3 or 2.7 or 3.4) executable available in PATH
* from the Windows Python launched `py` if available
Individual changes were:
* Update tools/venv3.py to support py launcher on Windows
* Fix typo in help message
* More explicit calls with space protection
* Complete refactoring to take advantage of the python runtime, and control of the compatible version to use.
2018-11-15 18:17:36 -05:00
|
|
|
|
2020-06-01 18:18:38 -04:00
|
|
|
def subprocess_output_with_print(cmd, env=None, shell=False):
|
|
|
|
|
if env is None:
|
|
|
|
|
env = os.environ
|
|
|
|
|
print('+ {0}'.format(subprocess.list2cmdline(cmd)) if isinstance(cmd, list) else cmd)
|
|
|
|
|
return subprocess.check_output(cmd, env=env, shell=shell)
|
|
|
|
|
|
|
|
|
|
|
2019-02-28 14:35:58 -05:00
|
|
|
def get_venv_python_path(venv_path):
|
2018-11-07 20:16:16 -05:00
|
|
|
python_linux = os.path.join(venv_path, 'bin/python')
|
|
|
|
|
if os.path.isfile(python_linux):
|
2019-02-28 14:35:58 -05:00
|
|
|
return os.path.abspath(python_linux)
|
2018-11-14 16:57:40 -05:00
|
|
|
python_windows = os.path.join(venv_path, 'Scripts\\python.exe')
|
2018-11-07 20:16:16 -05:00
|
|
|
if os.path.isfile(python_windows):
|
2019-02-28 14:35:58 -05:00
|
|
|
return os.path.abspath(python_windows)
|
2018-11-07 20:16:16 -05:00
|
|
|
|
|
|
|
|
raise ValueError((
|
|
|
|
|
'Error, could not find python executable in venv path {0}: is it a valid venv ?'
|
|
|
|
|
.format(venv_path)))
|
|
|
|
|
|
Update tools/venv3.py to support py launcher on Windows (#6493)
Following some inconsistencies occurred during by developments, and in the light of #6508, it decided to wrote a PR that will take fully advantage of the conversion from bash to python to the development setup tools.
This PR adresses several issues when trying to use the development setup tools (`tools/venv.py` and `tools/venv3.py`:
* on Windows, `python` executable is not always in PATH (default behavior)
* even if the option is checked, the `python` executable is not associated to the usually symlink `python3` on Windows
* on Windows again, really powerful introspection of the available Python environments can be done with `py`, the Windows Python launcher
* in general for all systems, `tools/venv.py` and `tools/venv3.py` ensures that the respective Python major version will be used to setup the virtual environment if available.
* finally, the best and first candidate to test should be the Python executable used to launch the `tools/venv*.py` script. It was not relevant before because it was shell scripts, but do it is.
The logic is shared in `_venv_common.py`, and will be called appropriately for both scripts. In priority decreasing order, python executable will be search and tested:
* from the current Python executable, as exposed by `sys.executable`
* from any python or pythonX (X as a python version like 2, 3 or 2.7 or 3.4) executable available in PATH
* from the Windows Python launched `py` if available
Individual changes were:
* Update tools/venv3.py to support py launcher on Windows
* Fix typo in help message
* More explicit calls with space protection
* Complete refactoring to take advantage of the python runtime, and control of the compatible version to use.
2018-11-15 18:17:36 -05:00
|
|
|
|
2019-04-05 18:01:09 -04:00
|
|
|
def prepare_venv_path(venv_name):
|
|
|
|
|
"""Determines the venv path and prepares it for use.
|
|
|
|
|
|
|
|
|
|
This function cleans up any Python eggs in the current working directory
|
|
|
|
|
and ensures the venv path is available for use. The path used is the
|
|
|
|
|
VENV_NAME environment variable if it is set and venv_name otherwise. If
|
|
|
|
|
there is already a directory at the desired path, the existing directory is
|
|
|
|
|
renamed by appending a timestamp to the directory name.
|
2018-11-19 14:47:14 -05:00
|
|
|
|
|
|
|
|
:param str venv_name: The name or path at where the virtual
|
2019-04-05 18:01:09 -04:00
|
|
|
environment should be created if VENV_NAME isn't set.
|
2018-11-19 14:47:14 -05:00
|
|
|
|
2019-04-05 18:01:09 -04:00
|
|
|
:returns: path where the virtual environment should be created
|
|
|
|
|
:rtype: str
|
|
|
|
|
|
|
|
|
|
"""
|
2018-11-07 20:16:16 -05:00
|
|
|
for path in glob.glob('*.egg-info'):
|
|
|
|
|
if os.path.isdir(path):
|
|
|
|
|
shutil.rmtree(path)
|
|
|
|
|
else:
|
|
|
|
|
os.remove(path)
|
|
|
|
|
|
2018-11-19 14:47:14 -05:00
|
|
|
env_venv_name = os.environ.get('VENV_NAME')
|
|
|
|
|
if env_venv_name:
|
|
|
|
|
print('Creating venv at {0}'
|
|
|
|
|
' as specified in VENV_NAME'.format(env_venv_name))
|
|
|
|
|
venv_name = env_venv_name
|
|
|
|
|
|
2018-11-07 20:16:16 -05:00
|
|
|
if os.path.isdir(venv_name):
|
|
|
|
|
os.rename(venv_name, '{0}.{1}.bak'.format(venv_name, int(time.time())))
|
|
|
|
|
|
2019-04-05 18:01:09 -04:00
|
|
|
return venv_name
|
|
|
|
|
|
|
|
|
|
|
2019-07-02 16:45:57 -04:00
|
|
|
def install_packages(venv_name, pip_args):
|
2019-04-05 18:01:09 -04:00
|
|
|
"""Installs packages in the given venv.
|
|
|
|
|
|
|
|
|
|
:param str venv_name: The name or path at where the virtual
|
|
|
|
|
environment should be created.
|
|
|
|
|
:param pip_args: Command line arguments that should be given to
|
|
|
|
|
pip to install packages
|
|
|
|
|
:type pip_args: `list` of `str`
|
|
|
|
|
|
|
|
|
|
"""
|
2019-02-28 14:35:58 -05:00
|
|
|
# Using the python executable from venv, we ensure to execute following commands in this venv.
|
|
|
|
|
py_venv = get_venv_python_path(venv_name)
|
2020-11-06 05:17:41 -05:00
|
|
|
subprocess_with_print([py_venv, os.path.abspath('tools/pipstrap.py')])
|
2020-06-01 18:18:38 -04:00
|
|
|
# We only use this value during pip install because:
|
|
|
|
|
# 1) We're really only adding it for installing cryptography, which happens here, and
|
|
|
|
|
# 2) There are issues with calling it along with VIRTUALENV_NO_DOWNLOAD, which applies at the
|
|
|
|
|
# steps above, not during pip install.
|
|
|
|
|
env_pip_no_binary = os.environ.get('CERTBOT_PIP_NO_BINARY')
|
|
|
|
|
if env_pip_no_binary:
|
|
|
|
|
# Check OpenSSL version. If it's too low, don't apply the env variable.
|
|
|
|
|
openssl_version_string = str(subprocess_output_with_print(['openssl', 'version']))
|
|
|
|
|
matches = re.findall(r'OpenSSL ([^ ]+) ', openssl_version_string)
|
|
|
|
|
if not matches:
|
|
|
|
|
print('Could not find OpenSSL version, not setting PIP_NO_BINARY.')
|
|
|
|
|
else:
|
|
|
|
|
openssl_version = matches[0]
|
|
|
|
|
|
|
|
|
|
if LooseVersion(openssl_version) >= LooseVersion('1.0.2'):
|
|
|
|
|
print('Setting PIP_NO_BINARY to {0}'
|
|
|
|
|
' as specified in CERTBOT_PIP_NO_BINARY'.format(env_pip_no_binary))
|
|
|
|
|
os.environ['PIP_NO_BINARY'] = env_pip_no_binary
|
|
|
|
|
else:
|
|
|
|
|
print('Not setting PIP_NO_BINARY, as OpenSSL version is too old.')
|
2019-02-28 14:35:58 -05:00
|
|
|
command = [py_venv, os.path.abspath('tools/pip_install.py')]
|
2019-04-05 18:01:09 -04:00
|
|
|
command.extend(pip_args)
|
2019-02-28 14:35:58 -05:00
|
|
|
subprocess_with_print(command)
|
2020-06-01 18:18:38 -04:00
|
|
|
if 'PIP_NO_BINARY' in os.environ:
|
|
|
|
|
del os.environ['PIP_NO_BINARY']
|
2018-11-07 20:16:16 -05:00
|
|
|
|
|
|
|
|
if os.path.isdir(os.path.join(venv_name, 'bin')):
|
|
|
|
|
# Linux/OSX specific
|
|
|
|
|
print('-------------------------------------------------------------------')
|
|
|
|
|
print('Please run the following command to activate developer environment:')
|
|
|
|
|
print('source {0}/bin/activate'.format(venv_name))
|
|
|
|
|
print('-------------------------------------------------------------------')
|
2018-11-09 19:17:17 -05:00
|
|
|
elif os.path.isdir(os.path.join(venv_name, 'Scripts')):
|
2018-11-07 20:16:16 -05:00
|
|
|
# Windows specific
|
|
|
|
|
print('---------------------------------------------------------------------------')
|
|
|
|
|
print('Please run one of the following commands to activate developer environment:')
|
Update tools/venv3.py to support py launcher on Windows (#6493)
Following some inconsistencies occurred during by developments, and in the light of #6508, it decided to wrote a PR that will take fully advantage of the conversion from bash to python to the development setup tools.
This PR adresses several issues when trying to use the development setup tools (`tools/venv.py` and `tools/venv3.py`:
* on Windows, `python` executable is not always in PATH (default behavior)
* even if the option is checked, the `python` executable is not associated to the usually symlink `python3` on Windows
* on Windows again, really powerful introspection of the available Python environments can be done with `py`, the Windows Python launcher
* in general for all systems, `tools/venv.py` and `tools/venv3.py` ensures that the respective Python major version will be used to setup the virtual environment if available.
* finally, the best and first candidate to test should be the Python executable used to launch the `tools/venv*.py` script. It was not relevant before because it was shell scripts, but do it is.
The logic is shared in `_venv_common.py`, and will be called appropriately for both scripts. In priority decreasing order, python executable will be search and tested:
* from the current Python executable, as exposed by `sys.executable`
* from any python or pythonX (X as a python version like 2, 3 or 2.7 or 3.4) executable available in PATH
* from the Windows Python launched `py` if available
Individual changes were:
* Update tools/venv3.py to support py launcher on Windows
* Fix typo in help message
* More explicit calls with space protection
* Complete refactoring to take advantage of the python runtime, and control of the compatible version to use.
2018-11-15 18:17:36 -05:00
|
|
|
print('{0}\\Scripts\\activate.bat (for Batch)'.format(venv_name))
|
2018-11-07 20:16:16 -05:00
|
|
|
print('.\\{0}\\Scripts\\Activate.ps1 (for Powershell)'.format(venv_name))
|
|
|
|
|
print('---------------------------------------------------------------------------')
|
|
|
|
|
else:
|
|
|
|
|
raise ValueError('Error, directory {0} is not a valid venv.'.format(venv_name))
|