ModuleNotFoundError: No module named 'setuptools._distutils' #2353
Comments
|
This one doesn't happen for every package, I haven't quite narrowed it down but I think it's related to having a pyproject.toml or |
|
I had same issue. Removing pyproject.toml from the library which failed to install pass through it |
|
That's true, and a useful workaround, but I think that's just because with no pyproject.toml, setuptools 50 doesn't get installed in the first place. So anyone can avoid this problem for now by specifying setuptools<50 in their pyproject.toml, but the fact that that works probably isn't relevant for debugging setuptools, sadly. Oh well. E.g. |
This commit resolves recent catastrophic upstream breakage introduced by setuptools 50.0, the newest stable release of everyone's least favourite build tool. Unrelatedly, this commit also optimizes a significant common edge case when registering types with the beartypistry singleton (i.e., builtins) and exercises all remaining edge cases in kinds of parameters annotated with PEP-compliant type hints. (Glorious hoarfrost inundates specular peculiarities!)
|
So, setuptools 50.0 is fundamentally broken and breaks the entire Python ecosystem – both open-source and not. Well, isn't that special. Heads need rolling (especially those currently attached to the still-functioning torsos of managerial project leads). Until the community tastes sweet vengeance, the following is a slightly saner solution than @dHannasch's excellent starting point: That is to say, downstream projects should probably only blacklist the specific version of setuptools known to catastrophically fail under the fairly safe assumption that the next stable release will either hopefully revert or perhaps even correctly fix the breakage. I can confirm the above circumvention behaves as expected in a project just maliciously blind-sided by this packaging horror show. Passing Die, setuptools 50.0! Die! 🩸 |
|
How to resolve this issue? please give us at least a temporary solution. |
|
@shakthifuture Setting environment variable $ export SETUPTOOLS_USE_DISTUTILS=stdlib
$ pip3 install […] |
|
@simmel thank you, it working. |
|
I'm unable to replicate the reported issue. When I attempt to install the reported package, it fails to install on another dependency: Is there an example I could follow to replicate the failure? |
|
I've confirmed that setuptools 50 isn't strictly implicated. The tempora project uses a similar pyproject.toml and building it from source on Setuptools 50 works fine: The error message Please let me know what steps might be needed to create the environment in which your builds fail. If possible, put them together in a Dockerfile (preferred) or script that reproduces the issue. Thanks. |
|
This Dockerfile is somewhat convoluted, but this is the simplest way I've found to reproduce this problem so far: EDIT: The installation succeeds if you set |
|
I've been able to consistently reproduce this with a Clearly there is some case where an isolated build isn't being properly isolated, and it's managing to pick up a different |
|
OK - I'm in no way an expert on PEP-517, but I think the bug here is in If a [build-system]
requires = ["setuptools"]then After it does that, it eventually calls the ['/home/matt/some_venv/lib/python3.8/site-packages/pip/_vendor/pep517',
'/tmp/pip-build-env-5v90m1w9/site',
'/usr/lib/python38.zip',
'/usr/lib/python3.8',
'/usr/lib/python3.8/lib-dynload',
'/usr/local/lib/python3.8/dist-packages',
'/usr/lib/python3/dist-packages',
'/tmp/pip-build-env-5v90m1w9/overlay/lib/python3.8/site-packages',
'/tmp/pip-build-env-5v90m1w9/normal/lib/python3.8/site-packages']The overlay directory is after the system site packages directory, which means that any build dependencies installed by I think there's one bug in each here: the |
|
There is, in fact, an old pip issue for exactly this bug. pypa/pip#6264 (comment). |
man you've just saved my life 😄 |
This code aims at aligning the CI tests across the different grimoirelab components. Python 3.5 is removed as its support period has ended and Python 3.6, 3.7 and 3.8 are now supported. The version of setuptools and pip has been downgraded as a hotfix to solve the failing CI tests. It must be related to the issue pypa/setuptools#2353. Signed-off-by: Venu Vardhan Reddy Tekula <venu@bitergia.com> Signed-off-by: lfpratik <pratikkaranje03@gmail.com>
pypa/setuptools#2353 Signed-off-by: David Galloway <dgallowa@redhat.com>
pypa/setuptools#2353 Signed-off-by: David Galloway <dgallowa@redhat.com>
pypa/setuptools#2353 Signed-off-by: David Galloway <dgallowa@redhat.com> (cherry picked from commit 4ab2df1)
Somehow, adding tbump as a dependency made tox upset with setuptools. I regenerated the poetry.lock, and added SETUPTOOLS_USE_DISTUTILS=stdlib to the testenv envvars based on pypa/setuptools#2353
Apparently, version 60.X (up including 62) introduces a bug manifesting in imports not found: ImportError: cannot import name 'build_py' from 'setuptools._distutils.command' pypa/setuptools#2353 Change-Id: I4c08d61ed95998221fa560915011f5ad2ef8f58b Reviewed-by: Christian Tismer <tismer@stackless.com>
This commit resolves recent catastrophic upstream breakage introduced by setuptools 50.0 and pip 22.2.0, the newest stable release of everyone's least favourite build tools. Sadly, doing so requires temporarily disabling project-wide support for the tooling-agnostic "pyproject.toml" file -- which setuptools and pip continually demonstrate that they are unwilling to sanely support. ## Issues Resolved * #2, detailed above. * #3, detailed below. * pypa/setuptools#2353 and pypa/pip#6264, resolving recent catastrophic upstream breakage introduced by setuptools 50.0 and pip 22.2.0, the newest stable release of everyone's least favourite build tools. Sadly, doing so requires temporarily disabling project-wide support for the tooling-agnostic `pyproject.toml` file -- which setuptools and pip continually demonstrate that they are unwilling to sanely support. (Unctuous tempestuousness of pestilence!)
This minor release resolves a growing cacophony of compatibility issues that have accrued in the two-and-a-half years since BETSE's last prior stable release (i.e., BETSE 1.1.1 (Nicer Nestor) in the pre-pandemic twilight of November, 2019). BETSE authors gratefully thank Dr. Levin at the Levin Lab, Tufts University for his continued patronage of BETSE. Noteworthy changes include: ## Hosting Improved * **GitLab -> GitHub.** BETSE's `git` repository has been officially migrated from our prior host at GitLab to our new host at GitHub, mostly so as to centralize the maintenance burden of continuous integration (CI) workflows across this and the upstream @beartype project. Specifically: * Our prior GitLab-specific GitLab-CI and Windows-specific Appveyor CI configurations have been supplanted wholesale with our standard GitHub-specific GitHub Actions CI workflows for both package testing and publication. * Our front-facing `README.rst` documentation has been trivially revised to reference GitHub rather than GitLab. * Our prior GitLab-specific `tox.ini` configuration and `doc/rst/RELEASE.rst documentation have been supplanted wholesale with actively maintained and more GitHub-friendly equivalents liberally harvested from our upstream @beartype project. ## Compatibility Improved * **Python >= 3.9.0.** BETSE now officially supports both the Python 3.9.x and 3.10.x series. * **macOS Aqua detection.** BETSE now detects the macOS-specific Aqua display server with significantly more robust logic. Previously, that detection unexpectedly raised exceptions under continuous integration (CI) workflows hosted by GitHub Actions. Now, that detection has been generalized to be resilient against edge cases – including: * The absence of the core macOS `/System/Library/Frameworks/Security.framework/Security` library. * The absence of the `OSError`-specific `strerror` instance variable on low-level exceptions raised during this detection. * **Windows environment variable detection.** BETSE now circumvents erroneous Windows-specific shell environments produced by the GitHub Actions Windows runner, which fails to define the critical `%LOCALAPPDATA%`, `%APPDATA%`, or `%HOME` shell environment variables. Specifically: * The `betse.util.app.meta.AppMetaABC.dot_dirname()` method now leverages the first of the following shell environment variables exported to the active Windows process via trivial iteration: `%LOCALAPPDATA%`, `%APPDATA%`, and our standard `get_home_dirname()` getter. Insanely, the GitHub Actions Windows runner fails to export the former two shell environment variables as well as the otherwise standard `%HOME%` shell environment variable, which doesn't leave BETSE with terribly many options in CI environments. * **Windows subdirectory detection.** BETSE now circumvents the erroneous Windows-specific implementation of the standard `os.path.commonpath()` function, which unsafely raises an exception rather than safely returning `False` when passed two pathnames residing on different Windows drives (e.g., `C:/`, `D:/`). Our `betse.util.path.dirs.is_subdir()` tester now catches and coerces that unsafe exception into a safe return value of `False`. ## Compatibility Broken * **Python < 3.8.0.** This release officially breaks backward compatibility by dropping support for the Python 3.5.x, 3.6.x, and 3.7.x series. The former two have officially hit their End-of-Life (EOL); the latter is a half-year away from doing so and no longer worth officially supporting. * **PIL (Pillow) < 7.0.0.** This release officially breaks backward compatibility by dropping support for PIL (Pillow) < 7.0.0. See below. ## Dependencies Bumped * **NumPy ≥ 1.22.0.** BETSE now requires NumPy ≥ 1.22.0, which dramatically modified the (admittedly private) install-time `numpy.distutils.__config__` API describing how NumPy was linked against various external third-party shared libraries (e.g., BLAS, LAPACK) at install-time. Our `betse.lib.numpy.numpys` submodule now accesses that private NumPy API *much* more carefully – with robust future-proofing against predicted breakage by future NumPy releases breaking that API yet again. * **PIL (Pillow) ≥ 7.0.0.** BETSE now requires PIL (Pillow) ≥ 7.0.0, which introduced the standard `pillow.__version__` attribute and deprecated the non-standard `pillow.PILLOW_VERSION` attribute. Doing so renders the codebase incompatible with PIL (Pillow) < 7.0.0. Relatedly, The `betse.util.py.module.pymodname.MODULE_NAME_TO_VERSION_ATTR_NAME` dictionary has removed the non-standard `PIL: 'PILLOW_VERSION'` entry. * **`pytest` ≥ 5.4.0,** which refactored the previously defined private `_pytest.capture.CaptureManager._getcapture()` method into the newly defined `private _pytest.capture._getmulticapture()` function, which the `betse.lib.setuptools.command.supcmdtest` submodule necessarily monkey-patches at test time to sanitize captured output for long-running tests. ## Features Improved. * **Runtime dependency validation.** BETSE now validates whether optional and mandatory dependencies satisfy requirements at application startup by manually validating dependency versions *before* deferring to increasingly unreliable `setuptools`-specific logic for doing so. Specifically: * The private `betse.lib.libs._iter_requirement_commands()` iterator has been generalized to accept items of the `REQUIREMENT_NAME_TO_COMMANDS` dictionary as codebase-agnostic tuples rather than codebase-specific `betse.metadata.RequirementCommand` instances. * In the `betse.lib.setuptools.setuptool` submodule: * The `die_unless_requirement(`) validator and `is_requirement()` tester have been generalized to manually validate dependency versions before deferring to `setuptools`-specific logic for doing so. * The `get_requirement_distribution_or_none()` getter docstring has been revised to note that that getter should *only* be called as a latch-ditch fallback. * **Traceback handling.** BETSE now drastically simplifies its handling of exception tracebacks. Previously, BETSE *only* printed tracebacks (i.e., call stack traces) for uncaught exceptions when explicitly passed either the `-v` or `--verbose` options at the command line. Clearly, this was bad. While admittedly non-human-readable and thus unsightly, tracebacks yield mission-critical insights into critical breakage. Tracebacks are often the only means that devs have of debugging issues in cloud-hosted continuous integration (CI) workflows providing *no* convenient filesystem (and hence logfile) access; likewise, tracebacks are the only means that end users have of forwarding tracebacks to devs for subsequent debugging. BETSE now *always* prints tracebacks to standard error (stderr) regardless of options passed at the command line *or* defined in a configuration file. ## Issues Resolved. * **Matplotlib stream plotting exception.** An exception previously raised by Matplotlib on animating streamplots has been resolved. * **NumPy auto-object array deprecations.** All currently non-fatal `numpy.VisibleDeprecationWarning` warnings resulting from NumPy's recent deprecation of **auto-object arrays** (i.e., the implicit creation of one-dimensional NumPy arrays of Python `list` objects when passed ragged `list` of `list` objects with *no* uniform length) have been resolved. Where possible, these arrays have been reverted to standard non-NumPy `list` of `list` objects; in all other cases, these arrays have been explicitly coerced into non-auto object arrays. * **Widespread deprecations.** A slew of other currently non-fatal deprecation warnings emitted by various third-party dependencies of BETSE have similarly been resolved. ## Installation Improved * **Install-time Python version enforced.** The minimum mandatory version of Python required by this project is now enforced at `setuptools`-based install time via the recently introduced `python_requires` `setup(`) key in our top-level `setup.py` installer. * **pypa/setuptools#2353 and pypa/pip#6264.** This release resolves recent catastrophic upstream breakage introduced by `setuptools` 50.0 and `pip` 22.2.0, the newest stable release of everyone's least favourite build tools. Sadly, doing so requires temporarily disabling project-wide support for the tooling-agnostic `pyproject.toml` file -- which `setuptools` and `pip` continually demonstrate that they are unwilling to sanely support. * **`setuptools` entry point.** The `betse` command installed by our top-level `setup.py` installer now correctly runs. Previously, our installer inadvertently produced a broken `betse` command by incorrectly monkey-patching the `setuptools` installation process. ## Tests Improved * **`pytest` warning resolved.** BETSE's test suite no longer issues a non-fatal warning under recent `pytest` versions. Specifically, our top-level `pytest.ini` configuration file now explicitly lists *all* custom `pytest` marks applied by our test suite. * **`pytest` warnings filters.** BETSE now defers to `pytest` warnings filters when detected as running under `pytest` at test-time, preventing BETSE's custom warnings filters from silently overwriting those predefined by `pytest`. Most test harnesses (including `pytest`) define sane default warnings filters as well as enabling users to externally configure warnings filters from project-wide configuration files. Ergo, the `pytest` harness knows better than we do. * **`tox` venv isolation validation.** BETSE's test suite now sports significantly improved `tox`-specific validation of whether this suite is safely isolated to a virtual environment (venv), avoiding spurious test failures with otherwise valid pipelines. Specifically: * The top-level `pytest`-specific `conftest.py` plugin has been generalized by: * Refactoring the existing private `_clean_imports()` function to: * Treat zipfiles on `sys.path` *not* isolated to the current `tox` venv as effectively isolated anyway, as zipfiles are effectively isolated from filesystem modification -- notably, `pip`- and `setuptools`-based package installation. * Reorder `sys.path` so as to shift import paths *not* isolated to the current `tox` venv to the end of this list, thus deprioritizing (but *not* removing) these paths. * Removed the obsolete private `_print_metadata()` function, most of which now resides in the `_clean_imports()` function. * **PyPy testing disabled.** BETSE's test suite has (hopefully temporarily) disabled all testing of PyPy. Sadly, scientific dependencies (including NumPy) are *not* sanely installable under macOS + PyPy. macOS ships with Accelerate, blatantly broken macOS-specific BLAS and LAPACK shared libraries that fundamentally break NumPy on installation. Since NumPy fails to ship macOS + PyPy wheels, NumPy installation under macOS + PyPy requires building NumPy from source against Accelerate, which then painfully fails. For now, disabling PyPy testing entirely is the only sensible choice. * **macOS test compatibility,** including: * The mostly incidental `test_dirs_get_mtime_newest()` unit test is now skipped under Apple macOS – due to what appear to be inconsistencies in the handling of nanosecond-resolution path timestamps under the macOS-specific HFS+ filesystem. (*Infallible infancy bellows the fancy libel!*)
pip install .suddenly started failing for many packages. Since setuptools just got a new version and pip didn't, and setuptools appears in the error, I'm guessing it's related to setuptools 50. Apologies if this turns out to be wrong.This can be seen in any number of repositories, such as https://github.com/dHannasch/tox-sitepackages-example.
This doesn't appear to be quite the same as #2352.
I don't fully understand all the implications of https://github.com/pypa/setuptools/issues/2350, but
SETUPTOOLS_USE_DISTUTILS=stdlibhas no effect on this (dittoSETUPTOOLS_USE_DISTUTILS=1), so I think this is a separate issue.Travis log:
The text was updated successfully, but these errors were encountered: