pep517 backend seems not defined correctly for pyproject-hooks=1.2.0

[theamericanaccount]

Please confirm the following

• I agree to follow the aio-libs Code of Conduct

• I have checked the current issues for duplicates.

• I understand this is open source software provided for free and that I might not receive a timely response.
• I am positive I am NOT reporting a (potential) security
  vulnerability, to the best of my knowledge. (These must be shared by
  submitting this report form instead, if
  any hesitation exists.)

• I am willing to submit a pull request with reporoducers as xfailing test cases or even entire fix. (Assign this issue to me.)

Describe the bug

Apparently the pep517 backend is not declared correctly in pyproject.toml as now pyproject-hooks=1.2.0 requires a semicolor and not a double colon anymore.
I'm still not really sure how to adapt it to work.
I've been absent from Python coding (not packaging) for a couple years and I've seen everybody switch to this pep517 (now pep660?) thing which at times seems even more messy than old setuptools.
Also it seems to build fine using the same version of pyproject-hooks in the Life / DogeOS's Android environment while it goes awry on GNU one.

To Reproduce

Run a reallymakepkg on the PKGBUILD at python-propcache-ur

Expected behavior

It should build.

Logs/tracebacks

pyproject-hooks 1.2.0 seems requiring declaring the backend with a double column instead than with a dot.

Python Version

3.12.7

propcache Version

It's not a pip build.

OS

Life / DogeOS (GNU / Arch environment)

Additional context

No response

[theamericanaccount]

I'm trying to fix the issue here.

EDIT: is fixed.

[theamericanaccount]

Ok so the issue seems that the .hooks must be entirely removed from the pyproject.toml's reported PEP517's backend and the __init__.py of <project_root>/packaging/pep517_backend module must instead expose the hooks submodule as an attribute.

I can't open a merge request because I've not forked the project through the fork button so github doesn't let me.

I've released the fix as v0.2.1 in the aforelinked fork but I suppose you'll want to stash my commits in a single one.

I have no idea why this issue didn't arise last week in the Life / DogeOS Android environment build since the build toolchain is pretty much the same.

I hope the same fix won't be needed for the rest of aio-libs modules/packages/libraries.

[theamericanaccount]

Ok so actually its not only 'hooks' that needs to be exposed as a pep517_backend attribute but also build_wheel from _backend.

[Dreamsorcerer]

I can't open a merge request because I've not forked the project through the fork button so github doesn't let me.

That is how you open a merge request. You need to merge from something, in Github parlance that thing is a fork. It takes a few seconds to create.

[webknjaz]

If something doesn't work, make sure to demonstrate how, using the supported tooling. It does work with pypa/build and pip wheel, and is compliant with the standards, obviously. Debugging any downstream automations is out of the scope of the project.

[webknjaz]

So far, there's no evidence of any bugs on our side. But the recent pyproject-hooks release changed something in the import path processing. Though, if it was problematic, it would've shown up in our CI since we invoke pypa/build, which depends on any version of pyproject-hooks. And so new CI runs should've picked up that version that was released over a month ago. And the known well-behaving downstreams (Fedora / Gentoo) would've hit a problem long ago.

[webknjaz]

Heres the CI run from 7 hours ago that successfully uses said version of the build frontend dependency: https://github.com/aio-libs/propcache/actions/runs/11947904396/job/33304604724#step:4:1.

Based on these observations, it's obvious that the downstream build tooling is broken somehow but fixing it is not something that is our concern. Closing.

[webknjaz]

I'll note for history that I checked pypa/pyproject-hooks#199 / pypa/pyproject-hooks#195. And these are the only things that I think might influence the behavior. So it might be dependent on the presence of importlib_metadata, its version or the version of CPython (due to the differences in importlib.metadata in stdlib).

But so far, these are just guesses. If somebody's able to reproduce whatever the problem is with pyproject-hooks, that would need to be explained in detail on their tracker.