Provide PyInstaller binaries (IDFGH-14261)

[nebkat]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Described the feature in detail and justified the reason for the request.
• Provided specific use cases and examples.

Feature description

Inspired by the releases provided by esptool, consider generating PyInstaller binaries for esp_idf_monitor.

Use cases

Setting esp-idf-monitor up on non-technical colleagues computers involves installing Python, explaining the use of python -m esp_idf_monitor and is generally somewhat of a chore.

This could be reduced to download, unzip and run 😃

Alternatives

No response

Additional context

This can be achieved by:

diff --git a/esp_idf_monitor/__main__.py b/esp_idf_monitor/__main__.py
index 1f7b826..79a656f 100644
--- a/esp_idf_monitor/__main__.py
+++ b/esp_idf_monitor/__main__.py
@@ -1,4 +1,4 @@
-from .idf_monitor import main
+from esp_idf_monitor.idf_monitor import main

 if __name__ == '__main__':
     main()

Required due to pyinstaller/pyinstaller#2560.

Followed by:

pyinstaller --onefile --name esp-idf-monitor esp_idf_monitor/__main__.py

[peterdragun]

Hi, thank you for the feature request, but we have decided that we won't do this now. The implementation of this itself would be easy, but adding such binaries would require a lot of maintenance from our side (signing binaries, tests, etc.). There are a lot of issues that we need to constantly fix in esptool because of this. On top of that, binaries from PyInstaller often get marked by some antivirus programs as false positives. Python applications are primarily supposed to be interpreted, and using PyInstaller is causing multiple drawbacks.

We may reconsider this in the future if more requests from users come. I hope you understand.

[nebkat]

Totally understand, I know PyInstaller is not the best.

If nebkat@202fff0 could be considered so I can maintain local builds for internal use without any modifications that would be great, but no problem if not.

We may reconsider this in the future if more requests from users come.

A side note - as a long time ESP-IDF developer I have noticed that there are a quite a lot of tools and options in the ecosystem that do not seem to be very well known - otatool, parttool and esptool-js to name a few. In fact I was only made aware of the esptool binary releases a few weeks ago by a colleague who had discovered them attempting to recreate the binaries himself.

After some thought I think the best way to improve this would be to split up the API Guides section of the documentation into separate "Development Guides" and "API Guides". Topics such as Build System, C++ Support, Tools and Unit Testing are easily lost amongst the peripheral API links.

I can create an issue on esp-idf if you'd be interested in some more ideas - we spend a lot of time on DevOps and would love to have a central resource to share this information with others.

[peterdragun]

If nebkat@202fff0 could be considered so I can maintain local builds for internal use without any modifications that would be great, but no problem if not.

I don't see a reason why not. Feel free to create a PR, and we will include it.

I can create an issue on esp-idf if you'd be interested in some more ideas - we spend a lot of time on DevOps and would love to have a central resource to share this information with others.

We always welcome any ideas for improvements, so if you have any suggestions, we would be happy to hear about them. Thank you!