diff options
| author | Adrien Ferrand <adferrand@users.noreply.github.com> | 2020-09-02 21:45:38 +0300 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-09-02 21:45:38 +0300 |
| commit | 3ce87d1fcb1a11b554c9e22727d602cb86f0b8bf (patch) | |
| tree | 1cf55da2721862ddabe5a5ac7f5548482fab1b4d /snap | |
| parent | d62d853ea4c03676f1a10248d01b91aa61eaec3e (diff) | |
Test PIP_NO_BUILD_ISOLATION (#8255)
Fixes #8252
With @bmw we digged quite a lot on why the failure happens on ARM snap, and here we what we understood:
* the failure occurs since the version 50 of setuptools is available
* normally, we should not be impacted because the setuptools version used in the snap build should be the one installed by the `core20` base snap, because the build occurs in a `venv` created with `--system-site-packages`
* BUT associated with the build isolation provided by recent versions of pip (to implement PEP 517), a bad interaction happens: following the definition of the build system provided by `cryptography`, pip installs the most recent version of setuptools on a separate path for the build (because `cryptography` just asks for a minimal version of `setuptools`), then features of this version conflict with the old version of `setuptools` initially present
* the exact interaction is described here: https://github.com/pypa/pip/issues/6264#issuecomment-685230919. Basically the new version of `setuptools` triggers some hacks, that are then applied at runtime on the old version of `setuptools` that is also still available in `sys.path` at this point, and breaks the build.
To fix that, one can disable the isolation build on cryptography, by passing `PIP_NO_ISOLATION_BUILD=no` to pip. It is the purpose of this PR.
This will have the consequence to not be PEP 517 compliant: if needed the `cryptography` library will be built using the `setuptools` available in the system. In general I think it makes sense for the snap build purpose, since we control precisely the build environment, and makes consistent build that will not be broken by a new version of a build system if library maintainers did not provide a strict version of it in their build requirements. However we need now to take care about having a compatible build system for all libraries that may have specific requirements in their build system using the PEP 517 definition in `pyproject.toml`.
I think as of now that it is a safe move if we keep using the most recent version of `setuptools` available in Ubuntu 20.04, and it is the case here for snap builds. It may however be problematic if some libraries require another build system than `setuptools` and do not provide a fallback to a `setuptools` build. For the record, `dns-lexicon`, that I maintain, uses `poetry` and so a PEP 517 compliant definition of a build system, but provides also this fallback (https://github.com/AnalogJ/lexicon/blob/master/setup.py).
Full test suite compiling the snaps for the 3 architectures using this PR is available here: https://dev.azure.com/certbot/certbot/_build/results?buildId=2596&view=results
Diffstat (limited to 'snap')
| -rw-r--r-- | snap/snapcraft.yaml | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/snap/snapcraft.yaml b/snap/snapcraft.yaml index b29899c31..7076f7e18 100644 --- a/snap/snapcraft.yaml +++ b/snap/snapcraft.yaml @@ -75,6 +75,7 @@ parts: build-packages: [gcc, libffi-dev, libssl-dev, git, libaugeas-dev, python3-dev] build-environment: - SNAPCRAFT_PYTHON_VENV_ARGS: --system-site-packages + - PIP_NO_BUILD_ISOLATION: "no" override-pull: | snapcraftctl pull cd $SNAPCRAFT_PART_SRC |