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
gevent v 23.7.0
does not support PEP 517
#1971
Comments
Please look at the detailed output for your error message (if it's hidden, you may have to ask for it). gevent most certainly does support PEP 517, so your problem is unrelated to that and was likely some other error on your system (for example, missing compilation headers or missing compilers). It's curious that you'd even have to be building gevent though, as there are binary wheels for that platform on PyPI. |
I got this error when install by pdm
|
It looks like pdm also use PEP 517.
|
gevent certainly supports PEP517 --- which says nothing about file permission errors, just the existence of a You're not using source trees. You downloaded binary --- pre-built --- wheels taking PEP 517 out of the question entirely. I will note that those binary wheels did not come directly from PyPI but from third-party service that I know nothing about, so I cannot vouch for their contents. The tool(s) you are using apparently isn't setting up permissions correctly. Perhaps it has not been used to install packages that include C headers for other source packages to use? It's definitely something about your environment and tooling. The file it's failing to write is the header that greenlet installs. greenlet does not do this itself, it uses the standard packaging metadata to say "here's a header you should make available to other C libraries"; it's up to the installation tooling to do the right thing with those files, whatever the right thing is. I'm guessing this tool doesn't do anything special with those and just puts them in what Python's sysconfig reports to be its include directory. But on your system, your include directory isn't writable (likely because it belongs to another nix-managed package). Most of the time, people deal with non-writable shared directories by using a virtual environment, but I don't know what to tell you about nix and the other tools |
I found it just use a wheel |
I think I have found this problem too. I was on a project that had mainly It is possible to check using pip download gevent==23.9.0 --platform=manylinux2014_aarch64 --only-binary=:all: --python-version=3.9 --implementation=cp Refs.:
It outputs: ERROR: Could not find a version that satisfies the requirement gevent==23.9.0 (from versions: 20.12.0, 20.12.1, 21.1.0, 21.1.1, 21.1.2, 21.8.0, 21.12.0, 22.8.0, 22.10.1, 22.10.2) For my use case it was possible to stick with "older" gevent version. It is possible to test if somewheel exists: pip download gevent==22.10.2 --platform=manylinux2014_aarch64 --only-binary=:all: --python-version=3.9 --implementation=cp Checking that the pip download gevent==22.10.2 --platform=manylinux2014_x86_64 --only-binary=:all: --python-version=3.9 --implementation=cp In long term it would be really useful to have updated manylinux wheels published. |
poetry
Description:
poetry update
failed on• Updating gevent (22.10.2 -> 23.7.0): Failed
The text was updated successfully, but these errors were encountered: