gen_esp32part.py and deprecation of Python 2 (IDFGH-4606)

[Martin-Laclaustra]

Due to deprecation of Python 2 some Linux distributions have decided to remove the generic "python" executable from the path, forcing all code to explicitly declare which version of Python they require (A wise solution in my opinion, as it serves as "canary" for undefined code and prevents obscure errors, resolving the longstanding ambiguity, and still allows the use of older python 2 code). This change has been annoying when one's mind is in other tasks, but one must adapt to new times and deprecation was announced years ago.
I was proposing to change the shebang to #!/usr/bin/env python3 here espressif/arduino-esp32#4717 but me-no-dev suggested that a global upstream action might be suitable.

Best regards.

[Alvin1Zhang]

Thanks for reporting.

[dobairoland]

Hi @Martin-Laclaustra. Thank you for the suggestion.

Due to deprecation of Python 2 some Linux distributions have decided to remove the generic "python" executable from the path,

Which Linux distributions are you talking about? I think all of them provide some possibility to have a "python" defined.

I personally really don't like hardcoding "python3" into all of the scripts. (ESP-IDF have aprox. 160 scripts!). The right way is to setup the desired Python at the distribution level. We have recommendations regarding that in the documentation, for example for Ubuntu: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/linux-setup.html#setting-up-python-3-as-default-for-ubuntu-and-debian Please take a look at them to see if any of them are suitable for you.

Another argument against is that the upcoming release (v4.3) still supports Python 2. Forcing Python 3 in the scripts would mean a breaking change for developers who stuck with Python 2.

The default Python is used only when you run install.sh. A virtual Python environment is created and . export.sh switches to that environment and "python" will become the interpreter installed in that virtual environment. Hardcoding sheebangs also could mess things up and use another Python for which install.sh didn't install the required packages.

[dobairoland]

I also commented in the linked espressif/arduino-esp32#4717. I'm closing this now because currently a couple of workarounds are documented and we are tracking related future improvements elsewhere.

[adam-ah]

I personally really don't like hardcoding "python3" into all of the scripts. (ESP-IDF have aprox. 160 scripts!). The right way is to set up the desired Python at the distribution level.

All due respect, but this is not a liking / not-liking problem, but the standard way *nix systems are set up. The correct way is actually to add /usr/bin/env python3 to the scripts, and not asking users to hack system-level settings to run the code with a legacy runtime (NB., new systems come without Python 2 anyway, see https://wiki.ubuntu.com/FocalFossa/ReleaseNotes#Python3_by_default).

For a further discussion on why hacking /usr/bin/env is bad, see https://askubuntu.com/questions/817255/default-to-python3-for-usr-bin-env-python

Broadly, a lot of esp-idf users are engineers or hobby-engineers, therefore requiring them to modify their correctly set up systems is not the best approach and may break many other applications they rely on.

[dobairoland]

Thank you @adam-ah for your interest in this topic. I don't think that the current situation is ideal. We will work on improving it.

I'm aware of the content of the links. We will find a better solution which works for all of our customers.

I'll respond to your PR in a short time.