Release 1.1: Regression breaks setuptools builds

Question

Release 1.1: Regression breaks setuptools builds

jaraco opened this issue 8 months ago · 15 comments

In pypa/setuptools#4333, setuptools reports some emergent failures implicating the recent pyproject-hooks 1.1 release.

Answer 1 · 2024-04-29T19:25:46.000Z

More careful handling of the backend-path key from pyproject.toml.
Previous versions would load the backend and then check that it was loaded
from the specified path; the new version only loads it from the specified path.
The BackendInvalid exception is now a synonym for :exc:BackendUnavailable,
and code should move to using the latter name.

Answer 2 · 2024-04-29T19:36:00.000Z

#165 is the relevant PR -- /cc @abravalheri for awareness.

It's unclear to me what exactly is happening here from the setuptools failure, so not quite sure what the fix should/would be?

Answer 3 · 2024-04-29T19:50:31.000Z

My initial thought is that setuptools' builds were previously relying on metadata from an existing installation... and this change keeps that metadata hidden so that all that's around is the bootstrap metadata, which isn't sufficient to build setuptools (maybe?).

Answer 4 · 2024-04-29T19:52:30.000Z

Or, maybe the changes to avoid altering sys.path cause the metadata to be missing altogether.

Answer 5 · 2024-04-29T19:58:46.000Z

The sys.path with 1.0.0:

['/Users/pradyunsg/Developer/github/setuptools', '/Users/pradyunsg/Developer/github/setuptools/.venv/lib/python3.12/site-packages/pyproject_hooks/_in_process', '/Users/pradyunsg/.asdf/installs/python/3.12.0/lib/python312.zip', '/Users/pradyunsg/.asdf/installs/python/3.12.0/lib/python3.12', '/Users/pradyunsg/.asdf/installs/python/3.12.0/lib/python3.12/lib-dynload', '/Users/pradyunsg/Developer/github/setuptools/.venv/lib/python3.12/site-packages']

The sys.path with 1.1.0:

['/Users/pradyunsg/Developer/github/setuptools/.venv/lib/python3.12/site-packages/pyproject_hooks/_in_process', '/Users/pradyunsg/.asdf/installs/python/3.12.0/lib/python312.zip', '/Users/pradyunsg/.asdf/installs/python/3.12.0/lib/python3.12', '/Users/pradyunsg/.asdf/installs/python/3.12.0/lib/python3.12/lib-dynload', '/Users/pradyunsg/Developer/github/setuptools/.venv/lib/python3.12/site-packages']

It's... suboptimal... that _in_process is on sys.path with this setup.

Answer 6 · 2024-04-29T20:14:04.000Z

Yup, it's the changeover to using sys.meta_path rather than sys.path for loading the backend that's affected things here.

Answer 7 · 2024-04-29T21:11:17.000Z

I suspect adding a find_distributions (i.e. making it an importlib.metadata.DistributionFinder) will allow it to find the metadata for a backend and will likely address the concern.

Answer 8 · 2024-04-29T23:26:55.000Z

I also suspect this is the root cause of this issue: python-poetry/poetry#9351

Answer 9 · 2024-04-30T00:10:37.000Z

@mdagost No. See #191.

Answer 10 · 2024-04-30T00:15:05.000Z

Yes. Simply downgrading pyproject-hooks from 1.1.0 to 1.0.0 with no other changes fixes poetry install for all our projects.

Answer 11 · 2024-04-30T01:06:00.000Z

Sorry--update. I believe the root cause is that 1.0.0 was locked in the poetry.lock file, but then poetry itself pulled in 1.1.0 when it was pip installed. So there was a conflict. Either downgrading to 1.0.0 after pip installing, or upgrading to 1.1.0 in the lock file fixes things for me.

Answer 12 · 2024-04-30T08:44:25.000Z

@mdagost That sounds unrelated to this project, and specific to how Poetry is handling its environment and lockfile.

Please, let's keep any further Poetry-specific discussion in the Poetry issue tracker or the other issue in this repo.

Answer 13 · 2024-04-30T18:59:50.000Z

Correct. The root root cause was managing poetry with the lockfile, which is no bueno.

Answer 14 · 2024-06-19T05:20:33.000Z

CPython should stop shipping with prebuilt pip and invoking an install of prebuilt setuptools. Even Fedora has a problem with this.