Python requrements --- esp-windows-curses and sys_platform == 'win32'

[kacie_23]

Hello,

I am fairly new to the ESP-IDF, and I am trying to set up a Visual Studio Code environment for the ESP-IDF on Windows 10.
I have found very few sources on how to do this, and very few examples on a complete working environment.

The setup is using MSYS, with the traditional setup for windows, and the esp-idf and xtensa-esp32-elf seem to be installed and ready.
The current project looks is attached:

ESP32_IDF_T.rar

This is work in progress, but I have encountered a quite strange problem.

Firstly ... the following output is causing me some problems:

Code: [Select all] [Expand/Collapse]

1. C:/msys32/esp/esp-idf\requirements.txt
2. Namespace(requirements='C:/msys32/esp/esp-idf\\requirements.txt')
3. The following Python requirements are not satisfied:
4. esp-windows-curses; sys_platform == 'win32'

GeSHi © Codebox Plus Extension

I tried to fix this with the following command:

pip install -r C:\msys32\esp\esp-idf\requirements.txt ---- and esp-windows-curses version 0.1 is installed in Python, but the problem persist, and the message is not going away.

I tried to delete the line
file://${IDF_PATH}/tools/kconfig_new/esp-windows-curses; sys_platform == 'win32', from the requirements.txt, but this does not seem to be a good alternative.

An attitional problem is the mesage :

Code: [Select all] [Expand/Collapse]

1. <command-line>: fatal error: curses.h: No such file or directory

GeSHi © Codebox Plus Extension

And I just assume that this have something to do with the Python requirements.

When I try to run the make process, I get the following output:

Code: [Select all] [Expand/Collapse]

1. > Executing task: make -j8 V=1 <
2.  
3. Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...
4.        cygpath [-c HANDLE]
5.        cygpath [-ADHOPSW]
6.        cygpath [-F ID]
7.  
8. Convert Unix and Windows format paths, or output system path information
9.  
10. Output type options:
11.  
12.   -d, --dos             print DOS (short) form of NAMEs (C:\PROGRA~1\)
13.   -m, --mixed           like --windows, but with regular slashes (C:/WINNT)
14.   -M, --mode            report on mode of file (binmode or textmode)
15.   -u, --unix            (default) print Unix form of NAMEs (/cygdrive/c/winnt)
16.   -w, --windows         print Windows form of NAMEs (C:\WINNT)
17.   -t, --type TYPE       print TYPE form: 'dos', 'mixed', 'unix', or 'windows'
18.  
19. Path conversion options:
20.  
21.   -a, --absolute        output absolute path
22.   -l, --long-name       print Windows long form of NAMEs (with -w, -m only)
23.   -p, --path            NAME is a PATH list (i.e., '/bin:/usr/bin')
24.   -U, --proc-cygdrive   Emit /proc/cygdrive path instead of cygdrive prefix
25.                         when converting Windows path to UNIX path.
26.   -s, --short-name      print DOS (short) form of NAMEs (with -w, -m only)
27.   -C, --codepage CP     print DOS, Windows, or mixed pathname in Windows
28.                         codepage CP.  CP can be a numeric codepage identifier,
29.                         or one of the reserved words ANSI, OEM, or UTF8.
30.                         If this option is missing, cygpath defaults to the
31.                         character set defined by the current locale.
32.  
33. System information:
34.  
35.   -A, --allusers        use `All Users' instead of current user for -D, -O, -P
36.  -D, --desktop         output `Desktop' directory and exit
37.   -H, --homeroot        output `Profiles' directory (home root) and exit
38.  -O, --mydocs          output `My Documents' directory and exit
39.   -P, --smprograms      output Start Menu `Programs' directory and exit
40.  -S, --sysdir          output system directory and exit
41.  -W, --windir          output `Windows' directory and exit
42.   -F, --folder ID       output special folder with numeric ID and exit
43. Try `cygpath --help' for more information.
44.  
45. # mconf-idf is used only in MSYS
46. python /esp/esp-idf/tools/check_python_dependencies.py
47. MAKEFLAGS="" CC=cc LD=ld \
48. make -C /esp/esp-idf/tools/kconfig
49. make[1]: Entering directory '/esp/esp-idf/tools/kconfig'
50. cc -c  -DCURSES_LOC="<curses.h>" -DLOCALE -MMD -MP -I "." -I "/esp/esp-idf/tools/kconfig"  /esp/esp-idf/tools/kconfig/mconf.c -o mconf.o
51. <command-line>: fatal error: curses.h: No such file or directory
52. compilation terminated.
53. make[1]: *** [Makefile:173: mconf.o] Error 1
54. make[1]: Leaving directory '/esp/esp-idf/tools/kconfig'
55. C:/msys32/esp/esp-idf\requirements.txt
56. Namespace(requirements='C:/msys32/esp/esp-idf\\requirements.txt')
57. The following Python requirements are not satisfied:
58. esp-windows-curses; sys_platform == 'win32'
59. Please follow the instructions found in the "Set up the tools" section of ESP-IDF Getting Started Guide
60. make: *** No rule to make target 'check_python_dependencies', needed by 'all'.  Stop.
61. The terminal process terminated with exit code: 2
62.  
63. Terminal will be reused by tasks, press any key to close it.

GeSHi © Codebox Plus Extension

[ESP_Roland]

I would recommend to use the Windows tools installer and consequently, the windows command line to setup IDF for use of Visual Studio Code.

And please use IDF version v4.0 for now as there are a couple of issues in the master branch we have already fixed internally but are not yet published.

[kacie_23]

Thank you.
I have tried 4 different approaches with Msys2, Windows installer and VS Code, and none have worked perfectly.
It is a bit painful to use the ESP-IDF with VS Code, but I am sure that It will be great eventually.

I will use PlatformIO as a temporary solution, since this seem to work quite well.
But I would prefer to use the ESP-IDF direcly without any 3-rd party solution.

[Aussie Susan]

The issue I've had with PlatformIO is that the SDK is V3 whereas the functions I wanted to use (in the BLE area) were all in V4.
Looking at the Platform IO forums, they all seem to be waiting for someone in the ESP32 world to port the V4 SDK over to them.
(Note that this experience was a month or so ago - I've not had time to try since)
Susan

[joczek]

Hi there,

after using 4.0.2 for a while, I noticed some limitations so I considered going 4.2.

04/2021 tryin' to get v4.2 of esp-idf up and running on my system while using python 3.9 (dont know if this is relevant).
However, I'm currently facing the same issue seeing this when trying to build inside CLion:

Code: Select all

The following Python requirements are not satisfied:
esp-windows-curses; sys_platform == 'win32'
To install the missing packages, please run "C:\Users\user1\esp\esp-idf\install.bat"
Diagnostic information:
    IDF_PYTHON_ENV_PATH: C:\Users\user1\AppData\Local\Programs\Python\Python39\python.exe
    Python interpreter used: C:\Users\user1\AppData\Local\Programs\Python\Python39\python.exe
CMake Error at C:/Users/user1/esp/esp-idf/tools/cmake/build.cmake:271 (message):
  Some Python dependencies must be installed.  Check above message for
  details.

has there been any progress or suggestion on how to make it somewhat usable on windows machines? as a note: I used the Installer v2.3 to install esp-idf.

[ESP_Roland]

https://github.com/espressif/idf-installer

There has been a lot of improvements regarding this. The newer versions of the installes setup a custom Python for ESP-IDF.

The issue is caused by the fact that IDE tools can pick up other Python interpreters different to the one which export.bat is working with.