Can't install tools with Python 3.11 (IDFGH-8671) #10116
Comments
github-actions
bot
changed the title
|
This needs more investigation, but it looks like this is caused by an old Cython issue (cython/cython#4461) closed by a year ago. There are also a couple of 3.11 issues in the gevent tracker: https://github.com/gevent/gevent/issues?q=is%3Aissue+is%3Aclosed We will try to build wheels of gevent for 3.11 which would solve this issue. |
|
Fix ETA, workarounds besides using docker, anything? |
|
I'm sorry I cannot give an ETA because the root cause is outside of our jurisdiction. The proper fix will come with your Linux distribution's package updates. The workarounds are:
A workaround from our side will be to provide wheels but it is unknown to us right now how to fix those issues (there are others, the reported failure is just the first one which pops up). BTW, what Linux distributions (and versions) are you using. Mine is a cutting edge rolling distribution and it still doesn't updated Python to 3.11. |
|
Clear Linux. We got Python 3.11 on 27/Oct |
espressif-bot
added
Status: In Progress
|
You could also try upgrading to a newer gevent version. The error is reproducible with |
|
Already known, as |
|
@dobairoland you mentioned the proper fix will come with my distro's packages. Can you briefly outline what needs to be done there? I can certainly do the required work. |
I realized later that gevent already provides wheels for Python 3.11. My mistake. I'm sorry for the delay but the solution is harder than I thought. In order to lift the restriction on gevent, we need to lift it on gdbgui. And that needs the lifting of the restriction on pygdbmi which requires to backport fixes not just to ESP-IDF. |
|
I have the same problem since updating to Fedora 37. |
|
Crosslinking cs01/gdbgui#447. Later we can revisit this issue and support gdbgui together with Python 3.11. For now it won't be supported. The workaround will be merged soon and linked to this issue. |
espressif-bot
added
Resolution: NA
|
Any ETA on 4.4.4? |
Testing should start next week, so maybe in 2-3 weeks depending on the number of found issues. |
|
I hit this trying to build our idf 4.2 based software on latest Debian; from the above thread I was not able to deduce what the proper workaround for this is, apart from setting up a whole new old-debian-version-chroot for building. Is there a way around this? |
On the v4.3 branch, I applied commit 3974be7 referenced above to allow the tools installation to complete. Then I can compile no problem on Fedora 37 which ships with Python 3.11. You may be able to perform something similar for the v4.2 branch. |
|
Thank you @mcdavsco , that's helpful! |
|
I'll try to backport the fix into the v4.3 and v4.2 branches. |
|
I'm running into this stuff after installing latest updates today on Debian 12 + VSCode extension (IDF v4.4.4). Where is this all coming from? Why is it trying to create 3.10 venv on a 3.11 system? |
I ran into a mess as well, I think part of it was related to what was already in my |
I assume the update you run for the Debian updated Python from 3.10 and 3.11. Vscode works differently as the issue reported here. You will have run the Vscode setup again. The ESP-IDF installer won't help in this case. Please see the Vscode documentation. |
|
Ok, I removed both ./espressif and esp-idf directories, uninstalled VSCode extension, and then tried to install everything from scratch again. Extension installer still stuck with the same console output. No python_env folder is even created. That's probably a separate extension-related bug. However, I managed to get IDF's install.sh working somehow. Prior to launching it I tried to install python3-gevent package system-wide, and obviously succeeded. Don't know if it has something to do with the end result, though. Then I wired 3.11 venv folder to VSCode extension. All in all, I think I introduced following changes:
Also I am now confused about the meaning of that drop-down on the VSCode installer screen, that lets you choose python path ( |
|
I'm having the same issue on MacOS 13.0.1 (22A400) on Apple Silicon if it's any help. |
|
System Python is 3.9.6 on both my Apple Silicon Mac running macOS Monterey 12.6.3 and my Intel Mac running macOS Ventura 13.2.1. However, I did experience this issue after linking Homebrew Python 3.11 ( |
|
Thanks @mykmelez, that helped me get around this issue! |
|
For me, I had to do these steps to make it work: |
|
@madskjeldgaard Did you find any development? Have you been able to find anything new about the topic? i am having the same problem after note: This error originates from a subprocess, and is likely not a problem with pip. Although I deleted and reinstalled many times, I always had problems in the same place. |
|
Please see the linked fixes in each release branch. If you are still experiencing this then you probably don't use the latest (bugfix) version of the release. |
|
Ran into this problem today on MacOS 12.6.1, where the install script chokes on gevent. Ran the command |
|
Thanks @pkkrusty, this worked for me as well. MacOS Ventura 13.4 |
|
Just if anyone runs into this issue like me: the fix hasn't been published on the stable release tagged with |
Answers checklist.
IDF version.
v4.4.2
Operating System used.
Linux
How did you build your project?
Other (please specify in More Information)
If you are using Windows, please specify command line type.
No response
What is the expected behavior?
Following the instructions provided for installing ESP-IDF v4.4.2, I expect the tools to install successfully.
What is the actual behavior?
Installation of tools fails with an error stating that
longintrepr.hcould not be found.Steps to reproduce.
Build or installation Logs.
More Information.
Fedora Workstation 37
The issue seems to be related to old versions of
gevent. New versions ofgeventcan be installed correctly.Installing ESP-IDF from the
masterbranch works as expected.The text was updated successfully, but these errors were encountered: