-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] 71.0.0 fails with backports.tarfile
on Python 3.8 when other backports imported
#4476
Comments
A slightly longer stack trace from a python3.10 install:
|
It works for me. It sounds like the issue may be isolated to PyInstaller. It's interesting that |
When I say it works for me, here's Dockerfile that works: from ubuntu:focal
run apt update
run apt upgrade -y
run apt install -y python3-pip python3-venv
run python3 -m venv .venv
run .venv/bin/pip install -U setuptools
cmd .venv/bin/python -c "import pkg_resources" We'll need to figure out what factors are necessary to trigger the failure. |
I am also encountering this issue. Can reproduce it with the following packages installed:
and then running:
|
Not sure what is happening, but with both 71.0.0 and 71.0.1 - my pytest flow stopped working We use pyfilesystem2 - which is using pkg_resources internally and has the same issue: pytest is failing here: $ venv38/bin/pytest -v
====================================== test session starts ======================================
platform linux -- Python 3.8.19, pytest-7.4.4, pluggy-1.5.0 -- venv38/bin/python
cachedir: .pytest_cache
benchmark: 4.0.0 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
configfile: setup.cfg
plugins: env-1.1.3, mock-3.14.0, error-for-skips-2.0.2, fail-slow-0.6.0, unordered-0.6.1, split-0.9.0, flask-1.3.0, timeout-2.3.1, benchmark-4.0.0, cov-5.0.0
collected 0 items / 1 error
==================== ERRORS =========================
_________________________________ ERROR collecting test session _________________________________
../.conda/envs/py38/lib/python3.8/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
<frozen importlib._bootstrap>:1014: in _gcd_import
???
<frozen importlib._bootstrap>:991: in _find_and_load
???
<frozen importlib._bootstrap>:975: in _find_and_load_unlocked
???
<frozen importlib._bootstrap>:671: in _load_unlocked
???
venv38/lib/python3.8/site-packages/_pytest/assertion/rewrite.py:186: in exec_module
exec(co, module.__dict__)
apps/myapp/myapp_test/conftest.py:13: in <module>
from myapp.db.models import SQLAlchemy
apps/myapp/myapp/__init__.py:11: in <module>
from myapp.config import setup_logging, setup_settings
apps/myapp/myapp/config/__init__.py:13: in <module>
import fs as fs_library
venv38/lib/python3.8/site-packages/fs/__init__.py:4: in <module>
__import__("pkg_resources").declare_namespace(__name__) # type: ignore
venv38/lib/python3.8/site-packages/pkg_resources/__init__.py:93: in <module>
from jaraco.text import (
venv38/lib/python3.8/site-packages/setuptools/_vendor/jaraco/text/__init__.py:12: in <module>
from jaraco.context import ExceptionTrap
venv38/lib/python3.8/site-packages/setuptools/_vendor/jaraco/context.py:17: in <module>
from backports import tarfile
E ImportError: cannot import name 'tarfile' from 'backports' (venv38/lib/python3.8/site-packages/backports/__init__.py) But note that - When I don't use pytest - it works fine. Workarounds:
|
Thanks larsevj. That detail is quite helpful. It implicates a problem when there are other backports.* packages present. I thought maybe the issue was that package isn't using pkgutil-style namespaces, but it is. I'm now thinking the issue might be that pkgutil-based namespace packages (such as 'backports') don't support loading from more than one location. |
It's not as simple as the two namespaces not being honored:
|
We just got bitten by a variant of this issue. We don't use PyInstaller, however in our installation directory for Python requirements there existed an "empty" |
Aha, so the issue appears to be when backports is added to
|
Thanks xolox for the additional detail. I do agree a latent
I believe that PEP 420 namespace packages do not have this problem, because they allow for dynamic recalculation of the |
I read through the extend_path source and confirmed that the I did find that I can work around the issue by clearing out the
So maybe that's what setuptools should do to work around the issue (until some day |
I'm thinking something like: diff --git a/setuptools/__init__.py b/setuptools/__init__.py
index 8b0e494f0..fbc41f205 100644
--- a/setuptools/__init__.py
+++ b/setuptools/__init__.py
@@ -7,6 +7,8 @@ import sys
from typing import TYPE_CHECKING
sys.path.extend(((vendor_path := os.path.join(os.path.dirname(os.path.dirname(__file__)), 'setuptools', '_vendor')) not in sys.path) * [vendor_path]) # fmt: skip
+# workaround for #4476
+sys.modules.pop('backports', None) # noqa: E402
import _distutils_hack.override # noqa: F401
import distutils.core Would do the trick. Unfortunately, that introduces 10 new nitpicky E402 lint errors:
|
Is someone available to test if the PR in #4486 fixes the issue? Maybe |
#4486 seems to be working for me as well. |
I'm getting this error on aws apprunner |
@Tolulade-A I'm confident that the Setuptools 71.0.3 release fixes the issue. Can you confirm that you're on |
I'm on setuptools>=67 and downgraded to setuptools>=50.0.0
|
Address error with `setuptools` and its dependencies. Relates to pypa/setuptools#4476
I faced a similar bug with python 3.10. It was fixed by downgrading to <70 pip install --force-reinstall -v "setuptools<70" |
backports.tarfile
on Python 3.8backports.tarfile
on Python 3.8 when other backports imported
On Azure DevOps I'm seeing this with setuptools 71.1.0 (i.e., > 71.0.3) when trying to create a source distribution in a Docker container running Python 3.10.10:
UPDATE: setuptools 71.0.4 also failed with the same error, but 70.3.0 worked. |
If you're still having the error on setuptools 71.0.4 or later, it's a different root cause. Please open a new issue and importantly describe a reproducer (or at least more detail about your environment such that we might be able to reproduce it). Crucial will be to describe what other packages you have installed in the environment where the failure occurs. |
- Fix setuptools version to be >= 71.0.3 to get the fix for pypa/setuptools#4476 (affects Nova CI)
- Fix setuptools version to be >= 71.0.3 to get the fix for pypa/setuptools#4476 (affects Nova CI)
- Fix setuptools version to be >= 71.0.3 to get the fix for pypa/setuptools#4476 (affects Nova CI)
Summary: - Fix setuptools version to be >= 71.0.3 to get the fix for pypa/setuptools#4476 (affects Nova CI) Pull Request resolved: #2873 Reviewed By: spcyppt Differential Revision: D60074162 Pulled By: q10 fbshipit-source-id: c3f6589657b616e2366b10e4fc926bffc8569212
Done. See #4509 |
Summary: - Fix setuptools version to be >= 71.0.3 to get the fix for pypa/setuptools#4476 (affects Nova CI) Pull Request resolved: #2873 Reviewed By: spcyppt Differential Revision: D60074162 Pulled By: q10 fbshipit-source-id: c3f6589657b616e2366b10e4fc926bffc8569212
this is work for me thank you |
to avoid running into an issue (pypa/setuptools#4476) with setuptools [ML-7273](https://iguazio.atlassian.net/browse/ML-7273)
I tried it, however the issue still persists for me. Versions are listed as under: Python 3.8.19 Issue is as follows:
|
If the issue isn't fixed by 71.0.4, then there's a more narrow environmental concern to be addressed. I notice you're using conda. Have you seen #4508? There was a bug in the |
setuptools version
setuptools==71.0.0
Python version
Python 3.8
OS
Linux
Additional environment information
No response
Description
CI jobs started tripping when using setuptools 71, released two hours ago.
setuptools
/backports.tarfile
, andPyInstaller
crate/cratedb-toolkit#201Expected behavior
CI builds work as expected.
How to Reproduce
No reproducer yet, but a stacktrace on GHA.
Output
-- https://github.com/crate/cratedb-toolkit/actions/runs/9982521975/job/27589490156?pr=196#step:6:229
The text was updated successfully, but these errors were encountered: