2018-11-07 20:16:16 -05:00
|
|
|
#!/usr/bin/env python
|
|
|
|
|
# pip installs packages using pinned package versions. If CERTBOT_OLDEST is set
|
|
|
|
|
# to 1, a combination of tools/oldest_constraints.txt,
|
|
|
|
|
# tools/dev_constraints.txt, and local-oldest-requirements.txt contained in the
|
|
|
|
|
# top level of the package's directory is used, otherwise, a combination of
|
|
|
|
|
# certbot-auto's requirements file and tools/dev_constraints.txt is used. The
|
|
|
|
|
# other file always takes precedence over tools/dev_constraints.txt. If
|
|
|
|
|
# CERTBOT_OLDEST is set, this script must be run with `-e <package-name>` and
|
|
|
|
|
# no other arguments.
|
|
|
|
|
|
|
|
|
|
from __future__ import print_function, absolute_import
|
|
|
|
|
|
|
|
|
|
import subprocess
|
|
|
|
|
import os
|
|
|
|
|
import sys
|
|
|
|
|
import re
|
|
|
|
|
import shutil
|
|
|
|
|
import tempfile
|
|
|
|
|
|
|
|
|
|
import merge_requirements as merge_module
|
|
|
|
|
import readlink
|
2019-01-18 20:09:19 -05:00
|
|
|
import strip_hashes
|
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
|
|
|
|
2018-11-07 20:16:16 -05:00
|
|
|
def find_tools_path():
|
|
|
|
|
return os.path.dirname(readlink.main(__file__))
|
|
|
|
|
|
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
|
|
|
|
2018-11-07 20:16:16 -05:00
|
|
|
def certbot_oldest_processing(tools_path, args, test_constraints):
|
|
|
|
|
if args[0] != '-e' or len(args) != 2:
|
|
|
|
|
raise ValueError('When CERTBOT_OLDEST is set, this script must be run '
|
|
|
|
|
'with a single -e <path> argument.')
|
|
|
|
|
# remove any extras such as [dev]
|
|
|
|
|
pkg_dir = re.sub(r'\[\w+\]', '', args[1])
|
|
|
|
|
requirements = os.path.join(pkg_dir, 'local-oldest-requirements.txt')
|
2019-01-17 18:21:13 -05:00
|
|
|
shutil.copy(os.path.join(tools_path, 'oldest_constraints.txt'), test_constraints)
|
2018-11-07 20:16:16 -05:00
|
|
|
# packages like acme don't have any local oldest requirements
|
|
|
|
|
if not os.path.isfile(requirements):
|
2019-01-17 18:21:13 -05:00
|
|
|
return None
|
2018-11-07 20:16:16 -05:00
|
|
|
|
|
|
|
|
return requirements
|
|
|
|
|
|
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
|
|
|
|
2018-11-07 20:16:16 -05:00
|
|
|
def certbot_normal_processing(tools_path, test_constraints):
|
|
|
|
|
repo_path = os.path.dirname(tools_path)
|
|
|
|
|
certbot_requirements = os.path.normpath(os.path.join(
|
|
|
|
|
repo_path, 'letsencrypt-auto-source/pieces/dependency-requirements.txt'))
|
|
|
|
|
with open(certbot_requirements, 'r') as fd:
|
|
|
|
|
data = fd.readlines()
|
|
|
|
|
with open(test_constraints, 'w') as fd:
|
2019-03-04 08:52:38 -05:00
|
|
|
data = "\n".join(strip_hashes.process_entries(data))
|
2019-02-20 10:00:59 -05:00
|
|
|
fd.write(data)
|
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
|
|
|
|
2019-01-17 18:21:13 -05:00
|
|
|
def merge_requirements(tools_path, requirements, test_constraints, all_constraints):
|
|
|
|
|
# Order of the files in the merge function matters.
|
|
|
|
|
# Indeed version retained for a given package will be the last version
|
|
|
|
|
# found when following all requirements in the given order.
|
|
|
|
|
# Here is the order by increasing priority:
|
|
|
|
|
# 1) The general development constraints (tools/dev_constraints.txt)
|
|
|
|
|
# 2) The general tests constraints (oldest_requirements.txt or
|
|
|
|
|
# certbot-auto's dependency-requirements.txt for the normal processing)
|
|
|
|
|
# 3) The local requirement file, typically local-oldest-requirement in oldest tests
|
|
|
|
|
files = [os.path.join(tools_path, 'dev_constraints.txt'), test_constraints]
|
|
|
|
|
if requirements:
|
|
|
|
|
files.append(requirements)
|
|
|
|
|
merged_requirements = merge_module.main(*files)
|
2018-11-07 20:16:16 -05:00
|
|
|
with open(all_constraints, 'w') as fd:
|
|
|
|
|
fd.write(merged_requirements)
|
|
|
|
|
|
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
|
|
|
|
2018-11-07 20:16:16 -05:00
|
|
|
def call_with_print(command, cwd=None):
|
|
|
|
|
print(command)
|
2018-11-14 16:57:40 -05:00
|
|
|
subprocess.check_call(command, shell=True, cwd=cwd or os.getcwd())
|
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
|
|
|
|
2019-04-09 16:39:41 -04:00
|
|
|
def pip_install_with_print(args_str):
|
|
|
|
|
command = '"{0}" -m pip install --disable-pip-version-check {1}'.format(sys.executable,
|
|
|
|
|
args_str)
|
|
|
|
|
call_with_print(command)
|
|
|
|
|
|
|
|
|
|
|
2018-11-07 20:16:16 -05:00
|
|
|
def main(args):
|
|
|
|
|
tools_path = find_tools_path()
|
|
|
|
|
working_dir = tempfile.mkdtemp()
|
[URGENT] Fix the CI system (#6485)
It is about the exit codes that are returned from the various scripts in tools during tox execution.
Indeed, tox relies on the non-zero exit code from a given script to know that something failed during the execution.
Previously, theses scripts were in bash, and a bash script returns an exit code that is the higher code returned from any of the command executed by the script. So if any command return a non-zero (in particular pylint or pytest), then the script return also non-zero.
Now that these scripts are converted into python, pylint and pytest are executed via subprocess, that returns the exit code as variables. But if theses codes are not handled explicitly, the python script itself will return zero if no python exception occured. As a consequence currently, Certbot CI system is unable to detect any test error or lint error, because there is no exception in this case, only exit codes from the binaries executed.
This PR fixes that, by handling correctly the exit code from the most critical scripts, install_and_test.py and tox.cover.py, but also all the scripts that I converted into Python and that could be executed in the context of a shell (via tox or directly for instance).
2018-11-08 11:35:07 -05:00
|
|
|
|
2019-01-08 23:45:16 -05:00
|
|
|
if os.environ.get('TRAVIS'):
|
|
|
|
|
# When this script is executed on Travis, the following print will make the log
|
|
|
|
|
# be folded until the end command is printed (see finally section).
|
|
|
|
|
print('travis_fold:start:install_certbot_deps')
|
|
|
|
|
|
2018-11-07 20:16:16 -05:00
|
|
|
try:
|
|
|
|
|
test_constraints = os.path.join(working_dir, 'test_constraints.txt')
|
|
|
|
|
all_constraints = os.path.join(working_dir, 'all_constraints.txt')
|
|
|
|
|
|
2019-01-17 16:02:35 -05:00
|
|
|
if os.environ.get('CERTBOT_NO_PIN') == '1':
|
|
|
|
|
# With unpinned dependencies, there is no constraint
|
2019-04-09 16:39:41 -04:00
|
|
|
pip_install_with_print(' '.join(args))
|
2018-11-07 20:16:16 -05:00
|
|
|
else:
|
2019-01-17 16:02:35 -05:00
|
|
|
# Otherwise, we merge requirements to build the constraints and pin dependencies
|
|
|
|
|
requirements = None
|
|
|
|
|
if os.environ.get('CERTBOT_OLDEST') == '1':
|
|
|
|
|
requirements = certbot_oldest_processing(tools_path, args, test_constraints)
|
|
|
|
|
else:
|
|
|
|
|
certbot_normal_processing(tools_path, test_constraints)
|
|
|
|
|
|
2019-01-17 18:21:13 -05:00
|
|
|
merge_requirements(tools_path, requirements, test_constraints, all_constraints)
|
Try another approach (#7022)
In #7019, a solution has been integrated to fix oldest tests execution in the corner cases described in #7014.
However this solution was not very satisfactory, as it consists in making a --force-reinstall for all requirements on each oldest tests (apache, certbot, acme, each dns plugin ...). As a consequence, the overall execution time of these tests increased from 5 min to 10 min.
In this PR I propose a more elegant solution: instead of reinstalling all dependencies, we force reinstall only the requirements themselves describe in the relevant oldest-requirements.txt files. This way only the packages that are potentially ignored by pip because they exists locally (acme, certbot, ...) are reinstalled.
The result is the same than in #7019 (we are sure that all packages are really installed by pip), but the very limited number of force reinstalled package here make the impact on execution time negligible.
As a consequence, I revert back also the tox environments to execute all oldest tests together.
A successful execution of oldest tests using this PR material in the context of a point release can be seen here: https://travis-ci.org/adferrand/certbot/builds/527513101
2019-05-02 18:17:11 -04:00
|
|
|
if requirements: # This branch is executed during the oldest tests
|
|
|
|
|
# First step, install the transitive dependencies of oldest requirements
|
|
|
|
|
# in respect with oldest constraints.
|
2019-04-09 16:39:41 -04:00
|
|
|
pip_install_with_print('--constraint "{0}" --requirement "{1}"'
|
|
|
|
|
.format(all_constraints, requirements))
|
Try another approach (#7022)
In #7019, a solution has been integrated to fix oldest tests execution in the corner cases described in #7014.
However this solution was not very satisfactory, as it consists in making a --force-reinstall for all requirements on each oldest tests (apache, certbot, acme, each dns plugin ...). As a consequence, the overall execution time of these tests increased from 5 min to 10 min.
In this PR I propose a more elegant solution: instead of reinstalling all dependencies, we force reinstall only the requirements themselves describe in the relevant oldest-requirements.txt files. This way only the packages that are potentially ignored by pip because they exists locally (acme, certbot, ...) are reinstalled.
The result is the same than in #7019 (we are sure that all packages are really installed by pip), but the very limited number of force reinstalled package here make the impact on execution time negligible.
As a consequence, I revert back also the tox environments to execute all oldest tests together.
A successful execution of oldest tests using this PR material in the context of a point release can be seen here: https://travis-ci.org/adferrand/certbot/builds/527513101
2019-05-02 18:17:11 -04:00
|
|
|
# Second step, ensure that oldest requirements themselves are effectively
|
|
|
|
|
# installed using --force-reinstall, and avoid corner cases like the one described
|
|
|
|
|
# in https://github.com/certbot/certbot/issues/7014.
|
|
|
|
|
pip_install_with_print('--force-reinstall --no-deps --requirement "{0}"'
|
|
|
|
|
.format(requirements))
|
|
|
|
|
|
|
|
|
|
pip_install_with_print('--constraint "{0}" {1}'.format(
|
|
|
|
|
all_constraints, ' '.join(args)))
|
2018-11-07 20:16:16 -05:00
|
|
|
finally:
|
2019-01-08 23:45:16 -05:00
|
|
|
if os.environ.get('TRAVIS'):
|
|
|
|
|
print('travis_fold:end:install_certbot_deps')
|
2018-11-07 20:16:16 -05:00
|
|
|
shutil.rmtree(working_dir)
|
|
|
|
|
|
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
|
|
|
|
2018-11-07 20:16:16 -05:00
|
|
|
if __name__ == '__main__':
|
2018-11-14 16:57:40 -05:00
|
|
|
main(sys.argv[1:])
|