-
Notifications
You must be signed in to change notification settings - Fork 4.3k
"No package metadata" during wheel build from source #9453
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
Comments
Yep, experiencing this as well. |
Temporary workaround for people using Arch who still have the previous package cached - downgrade python-prompt_toolkit:
|
Hi @dgilman and all, thanks for bringing this up. We only support toolkit version from 3.0.24 to 3.0.38 Line 42 in f437589
Please see @evanstucker-hates-2fa open issue prompt-toolkit/python-prompt-toolkit#1988 to the right repo. |
I understand it is not supported. However, at some point, you’ll be bumping the package version yourself and run into the same issue. And although I don’t know exactly where the pep517 build tooling is breaking down evidence suggests that prompt_toolkit is a red herring because its metadata can be successfully retrieved by importlib when not running within the awscli2 build process. |
macport aws is broken . $aws During handling of the above exception, another exception occurred: Traceback (most recent call last): |
alpine's
|
this issue here is that the main source file interpretation has been manipulated in the coding file distribution. |
I am pretty certain the problem is with the aws-cli packaging. Executing the affected python code manually with global installed prompt toolkit dependency (using arch) the import works as expected. |
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
The issue here is that the wheel build of awscli v2 from a source distribution is now failing with this exception after updating to the latest
prompt_toolkit
3.0.51. Note that this version ofprompt_toolkit
now uses pyproject.toml for its build system. The output from awscli2's build is:This appears to be the same issue brought up on the arch linux forums that also sometimes crops up with kubectl.
I am not sure exactly where the issue lies but I bring it up here because after digging into the issue a bit, I found that the issue happens when awscli2's
backends/pep517.py
is thebackend_path
used bypyproject_hooks
to find the package metadata. In other words, if I:pyproject_metadata
in this PRDistributionFinder.Context
toDistributionFinder.Context(name=name)
- or in other words, keep it from using awscli2'sbackends/pep517
as thebackend_path
, it correctly finds the import and the awscli2 build works. But that is clearly a bogus fix, it just disables yourbackends/pep517.py
and I don't think upstream is supposed to do that.This correlates with what people are saying on the Arch forums, and what I've seen locally: if I run a python REPL and just do
metadata.version("prompt_toolkit")
in there it finds the package OK, so there is something about how awscli2'sbackends/pep517.py
is injected into the importlib mechanisms that makes the build tooling unable to find system packages.I don't know enough about the pep517 build stuff to know conclusively where the problem is, maybe it is with
prompt_toolkit
, maybe it is withpyproject_hooks
, maybe it is with yourbackends/
dir. But it is the combination of all three that is glitching this out.Regression Issue
Expected Behavior
python -m build --no-isolation --wheel --outdir blah
should build the wheelCurrent Behavior
See exception above
Reproduction Steps
Run
python -m build --no-isolation --wheel --outdir blah
on python 3.13 withprompt_toolkit
3.0.51 installed.Possible Solution
No response
Additional Information/Context
No response
CLI version used
n/a
Environment details (OS name and version, etc.)
macOS 15.4, python 3.13
The text was updated successfully, but these errors were encountered: