Test SETUPTOOLS_USE_DISTUTILS = stdlib, local on GH Actions #2865
Conversation
…en invoking pytest
|
Well that's interesting. Tests are now failing on Python 3.10 for |
|
It does look like PyPy is also, separately, importing In this case, it appears to be pytest-virtualenv again: It seems that on PyPy, Oh, right. Now I remember. PyPy imports distutils in sysconfig: So it's not possible on PyPy to import Maybe pytest-virtualenv can be made to work without that import as well. In man-group/pytest-plugins@c08c4a8, I removed the import of pkg_resources and verified that with that change, one can load all of the pytest plugins without importing distutils. Unfortunately, the error still occurs, indicating that something else is probably importing pkg_resources before the test suite is loaded. Confirmed the issue is fixed with pytest-virtualenv, and now the issue exists with pytest-cov/coverage: It looks like At this point, I'm not confident I can prevent the import of distutils on PyPy, so I'll propose to disable that check on that platform. |
|
It looks like those last two commits aren't having any effect, probably because they take effect before the warnings are applied in the pytest.ini. I need to find a hook that applies them after the warnings filters are applied in pytest.ini. |
|
I see now that pytest configures the warnings for each item, loading from the ini file settings each time. So it seems it may not be possible to add contextual warnings (only for Python 3.10 or PyPy) (https://github.com/pytest-dev/pytest/blob/5d87a27434dada56ba69ef7b5fa014c321dc46f4/src/_pytest/warnings.py#L52). |
jaraco
force-pushed
the
github_workflows_SETUPTOOLS_USE_DISTUTILS
branch
from
955e4b1
to
c08b7ee
Compare
jaraco
force-pushed
the
github_workflows_SETUPTOOLS_USE_DISTUTILS
branch
from
c08b7ee
to
2ceec37
Compare
|
There's still a lingering error on DISTUTILS=local for PyPy. Pip is getting a BackendInvalid exception from pep517. Unfortunately, it masks all the details, so it's difficult to determine anything about why it's invalid. It looks like the only place that's raised is It appears as if pip/pep517 thinks that the build backend is not being loaded from the backend path. I'm not able to replicate the issue on my macOS environment with PyPy 3.7. I'm also unable to replicate the issue on Ubuntu with PyPy 3.6.9, but I am able to replicate it on the same OS with PyPy 3.6.12 (same version as failing in GHA). Specifically: FROM jaraco/multipy-tox
RUN wget https://downloads.python.org/pypy/pypy3.6-v7.3.3-linux64.tar.bz2 -O - | tar xjC /usr/local --strip-components 1
ENV PIP_USE_PEP517=
ENV SETUPTOOLS_USE_DISTUTILS=local
RUN git clone https://github.com/mkoeppe/setuptools
WORKDIR setuptools
RUN git checkout github_workflows_SETUPTOOLS_USE_DISTUTILS
CMD tox -e pypy -- -k upgrade_from_source -p no:cov -p no:xdist -xRunning pip directly without tox: FROM jaraco/multipy-tox
RUN wget https://downloads.python.org/pypy/pypy3.6-v7.3.3-linux64.tar.bz2 -O - | tar xjC /usr/local --strip-components 1
ENV PIP_USE_PEP517=
ENV SETUPTOOLS_USE_DISTUTILS=local
RUN git clone https://github.com/mkoeppe/setuptools
WORKDIR setuptools
RUN git checkout github_workflows_SETUPTOOLS_USE_DISTUTILS
RUN tox -e pypy --notest
RUN .tox/pypy/bin/python setup.py sdist
RUN .tox/pypy/bin/virtualenv env
CMD env/bin/pip install --force --upgrade dist/*.zipI patched pep517 as found in pip in order to get some more detail about the error: diff --git a/src/pip/_vendor/pep517/in_process/_in_process.py b/src/pip/_vendor/pep517/in_process/_in_process.py
index 954a4ab05..6f9328f8c 100644
--- a/src/pip/_vendor/pep517/in_process/_in_process.py
+++ b/src/pip/_vendor/pep517/in_process/_in_process.py
@@ -95,7 +95,7 @@ def _build_backend():
contained_in(obj.__file__, path)
for path in extra_pathitems
):
- raise BackendInvalid("Backend was not loaded from backend-path")
+ raise BackendInvalid(f"Backend was not loaded from backend-path {obj.__file__}, {extra_pathitems}")
if obj_path:
for path_part in obj_path.split('.'):
diff --git a/src/pip/_vendor/pep517/wrappers.py b/src/pip/_vendor/pep517/wrappers.py
index e031ed708..eaa18586c 100644
--- a/src/pip/_vendor/pep517/wrappers.py
+++ b/src/pip/_vendor/pep517/wrappers.py
@@ -43,6 +43,9 @@ class BackendInvalid(Exception):
self.backend_path = backend_path
self.message = message
+ def __str__(self):
+ return self.message
+
class HookMissing(Exception):
"""Will be raised on missing hooks."""And when I run with that pip, I get some useful information out of the error message: So somehow, even though pep517 is supposed to be doing an isolated build, the setuptools from the virtualenv is getting imported for After drilling down deep into the bowels of pip/pep517, I think I've figured out the issue. In I'm still unsure why these errors hadn't emerged before. Oh, it seems maybe I hadn't authorized the job to run. I've just authorized the job to run. So maybe these environments have never passed. |
|
I've found another use-case that fails on PyPy. If you set TOX_WORK_DIR to |
jaraco
force-pushed
the
github_workflows_SETUPTOOLS_USE_DISTUTILS
branch
from
6e3dd3a
to
15a2fa4
Compare
|
I realize now, the main reason why I didn't implement the tests this way in the first place is because it multiplies the test suite by 2x when most of the tests are irrelevant to the difference. That is, the intention was for all tests to run under |
…ion tests. Works around issue with upgrading on PyPy.
jaraco
force-pushed
the
github_workflows_SETUPTOOLS_USE_DISTUTILS
branch
from
15a2fa4
to
3542082
Compare
|
It's so close to passing. It's failing now on PyPy on macOS, one test failure that I've not seen before. |
|
The remaining failure is in |
|
Looking great, thanks for all your work! |
|
@jaraco did this break the CI? |
|
I don't think it did. I'm pretty sure it was pypa/pip#10641, presumably fixed in f2de347 / #2874. |
|
I think there might be a problem with using: [options.extras_require]
testing =
...
- pytest-virtualenv>=1.2.7
+ pytest-virtualenv @ git+https://github.com/jaraco/pytest-plugins@distutils-deprecated#subdirectory=pytest-virtualenvin I am almost sure PyPI forbid uploading packages with dependencies outside of PyPI. |
|
No description provided. |
|
PyPI does not validate the deps. They may be satisfied from third-party sources. |
@webknjaz I had a problem like this around a month ago with another project. I don't know when PyPI started forbidding distributions that list dependencies via URLs, but they do it now for sure. You can also check the CI logs:
|
Summary of changes
This also makes the integration workflow added in pypa/distutils#67 actually work.
Closes #2861
Pull Request Checklist
changelog.d/.(See documentation for details)