Trying to build a wheel of YARL with the command python -m build --wheel issued at the root returns an error from _backend.py
#1001
Comments
|
Hi, would this be reproducible under the UBI container? The traceback indicates a problem with Cython. The problem with frozenlist would support this theory. You could pin the version of Cython by setting the |
|
@hroncok have you seen any problems with this on Fedora recently? (short of that tmp dir recursion that's still unfixed) |
webknjaz
changed the title
python -m build --wheel issued at the root returns an error from _backend.py
|
For the record, I don't see anything about yarl in Fedora at all. I only know about this package via #992 via befeleme/pyp2spec#44 |
|
I suspect this fails silently: yarl/packaging/pep517_backend/_backend.py Lines 37 to 42 in bd5ff24 yarl/packaging/pep517_backend/_backend.py Line 266 in bd5ff24 |
|
Cython is not listed in Lines 1 to 9 in bd5ff24 |
|
But the log says: It would be helpful to see what Cython version was installed. |
|
Yeah, that's injected by the backend through the hook for wheels. The underlying pip invocation likely selects the latest Cython version 3.0.9 released yesterday. The previous release was in Jan. This would explain the timing. I only tagged you, Miro, since Fedora is close enough to RHEL so it might've shown up in your packaging automation by now. I'm sure it'll break in your RPMs soon. It seems to me Cython must've renamed imports (which aren't exactly public API, TBF). The import errors are suppressed and so this only fails on accessing the importables. Which is definitely a bug I need to address, probably asking Cython for a more stable API going forward. |
|
That was my first guess as well, but |
|
@MichaelGoldsbie where did you get build from / how do you install it? |
|
I cannot reproduce this: |
I got the build from PyPi: https://pypi.org/project/yarl/. I tried getting the wheel by--in a Python virtual environment--navigating to the root of the yarl directory and issuing the command python -m build --wheel. And yes, I can see the version of Cython here is 3.0.9. (Previously I was getting the packages from cloning the GitHub directory but for aiohttp I noticed that some necessary c-extension files were missing in https://github.com/aio-libs/aiohttp/tree/master/aiohttp, whereas they existed on PyPi). Oh, and I forgot to mention one other thing--I'm this exact same problem for the frozenlist package as well. |
|
Thanks for checking, Miro!
FWIW the wheels still get built just fine under Python 3.9 in our CI. Here's one of fresh jobs from earlier today: https://github.com/aio-libs/yarl/actions/runs/8171206597/job/22338955861?pr=1002#step:6:7830. Of course, it's not RHEL but I don't see why it'd be different, honestly. The aiohttp project is still packaged differently, and you can only compile C-extensions if you run extra commands like cythonizing files after cloning from Git. Check out the CI setup to learn exactly what's called there.
You did mention it. But as things stand, the information provided is not enough to declare it broken as there's no reproducer that works outside of your machine. You didn't demonstrate any proof of the Cython version that gets installed in the ephemeral build env, by the way. It's not the same as your venv. |
I mean, where did you get the |
|
python -m pip install build Requirement already satisfied: build in /{venv_home}/env/lib/python3.9/site-packages (1.1.1) |
Sorry, what do you mean by "ephemeral build env"? What more information can I provide to help with this? |
|
@Michael-B-G PEP 517 builds have the frontend create a temporary virtualenv, populate it with build deps, invoke building and then delete. It's not persisted anywhere, and so it's usually referred to as ephemeral — it only exists during the invocation of pypa/build or pip, or another frontend. I honestly don't know how to help you since you're the only person on the internet having this behavior so it must be something broken in your env. You could try putting a copy of that seemingly broken import right before the line with Increasing verbosity of all your commands could shed the light on unexpected things like hitting a custom package index instead of the PyPI. Do you have a pip config on disk, by the way? Another thing you could do is making and sharing an asciinema recording in hopes somebody would be able to spot something in your process. Besides that, you may try making a container that shows your problem. Without any usable way to reproduce it, I can only conclude this with "works on my machine" 🤷♂️ |
|
Additionally, may I ask for your motivation in building wheels by yourself? Most people shouldn't need it and the downstream distro users are usually expected to use what their ecosystem's curated software repositories provide. |
|
Thank you for your help. I tried with the -"I" flag as well but got the same results. I inserted a print(sys.path) statement just before the error occurs and got: ['/{venv_home}/yarl-1.9.4/packaging', '/{venv_home}/env/lib/python3.9/site-packages/pyproject_hooks/_in_process', '/usr/lib64/python39.zip', '/usr/lib64/python3.9', '/usr/lib64/python3.9/lib-dynload', '/tmp/build-env-qp95b833/lib64/python3.9/site-packages', '/tmp/build-env-qp95b833/lib/python3.9/site-packages'] I don't have a pip config on my disk. For verbosity, I would require this, right? https://verboselogs.readthedocs.io/en/latest/readme.html#:~:text=The%20verboselogs%20package%20extends%20Python's,predefined%20DEBUG%20and%20NOTSET%20levels. However, I am unable to install the logging package due to some syntax error, and I'm not sure if I feel like trying to troubleshoot this due to being a distraction from the main problem, but here's what it says: I'm hesitant to make a recording because I want to anonymize as much about the server (like its name) as I can, though I might consider it. |
You shouldn't need to install anything third party. There's By the way, compare Oh, and have you tried adding |
I was kinda expecting you'd be testing this on your machine or in a container/VM, not it production.. |
|
I wasn't testing in production--it was a shared dev server, yet its FQDN and other aspects of its directory path contained references to the company name. Regardless, I have no more need for this thread three months later. Thank you for your help, everyone! |
|
Alright, closing then. |
Describe the bug
Using Python 3.9.18
So, if I navigate to the root of the yarl directory and issue the command
python -m build --wheel, I get the following:The same thing happens if I try with building a wheel using frozenlist-1.4.1
To Reproduce
See above
Expected behavior
The wheel is built successfully.
Logs/tracebacks
Traceback (most recent call last): File "/{venv_home}/env/lib64/python3.9/site-packages/pyproject_hooks/_in_process/_in_process.py", line 353, in main() File "/{venv_home}/env/lib64/python3.9/site-packages/pyproject_hooks/_in_process/_in_process.py", line 335, in main json_out['return_val'] = hook(**hook_input['kwargs']) File "/{venv_home}/env/lib64/python3.9/site-packages/pyproject_hooks/_in_process/_in_process.py", line 251, in build_wheel return _build_backend().build_wheel(wheel_directory, config_settings, File "/usr/lib64/python3.9/contextlib.py", line 79, in inner return func(*args, **kwds) File "/tmp/py_dependencies/yarl-1.9.4/packaging/pep517_backend/_backend.py", line 287, in build_wheel with maybe_prebuild_c_extensions( File "/usr/lib64/python3.9/contextlib.py", line 119, in enter return next(self.gen) File "/tmp/py_dependencies/yarl-1.9.4/packaging/pep517_backend/_backend.py", line 266, in maybe_prebuild_c_extensions _cythonize_cli_cmd(cythonize_args) NameError: name '_cythonize_cli_cmd' is not defined ERROR Backend subprocess exited when trying to invoke build_wheelPython Version
Python 3.9.18multidict Version
yarl Version
OS
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: