ESPRESSIF IDF manager relies on incorrect python paths (IEP-1271)

[emaayan]

when attempting to install IDF tools in the manager i've often encountered errors when it does:

Executing <path_entered_in_idf_manager>python.exe <tools_path>idf_tools.py export --format=key-value
and i get something like this:
Executing null/Scripts/python.exe C:\Users\User\eclipse\cpp-2024-06\esp-idf-v5.1.4\tools\idf.py --list-targets
which naturally files with errors of files not found in python
the problem is that i'm using python i got from msys64, and is in my path.
so for some reason the IDF manager gets hooked into that.
there are several problems here:
the first is that this happens even in espressif IDE which is meant to come bundled in
i would have expected it to take the python exe from it's own variables

the other issue is that if the python environment is not valid (like missing a scripts folder like what happens in msys64) i would expect the plugin to at least alert that and not continue

[alirana01]

@emaayan are you using the offline installer or directly downloading IDE from github releases? Espressif IDE itself in standalone is not with python, also what is the output of these commands
where python
where python3

The python in your %USERPROFILE%\AppData\Local\Microsoft\WindowsApps is a parse point and see if you are able to run it on terminal from that directory. If it takes you to microsoft store you may have to download it from there and then try the installation of tools in ide

[emaayan]

I'm using the offline installer
, accoriding to the docs, the installer contains an embedded python, and doesn't require anything else to be installed
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/windows-setup.html

This means that from my pov, that when you add and esp idf framework, the plugin should not only check if the python exe is valid and exist. But also if it's an actually python and not store entry point, as well if entire folder it resides in complies with python enviorment structure, (for example not us-ng mingw64 python)

[alirana01]

This was also pointed out internally and the upcoming enhancements should fix this