args passed to main(...) are not parsed correctly

[marcelstoer]

• Operating system: macOS
• Python version: (python -V to check this) 3.6.5
• ESP hardware in use: any

What is the expected behaviour?

CLI args can be passed as-is to esptool.main(...) to get exactly the same behavior.

Actual behaviour

All of the below combinations trip up the parser. It fails with (highlight is mine)

usage: esptool [-h] [--chip {auto,esp8266,esp32}] [--port PORT] [--baud BAUD]
[--before {default_reset,no_reset,no_reset_no_sync}]
[--after {hard_reset,soft_reset,no_reset}] [--no-stub]
[--trace] [--override-vddsdio [{1.8V,1.9V,OFF}]]
{load_ram,dump_mem,read_mem,write_mem,write_flash,run,image_info,make_image,elf2image,read_mac,chip_id,flash_id,read_flash_status,write_flash_status,read_flash,verify_flash,erase_flash,erase_region,version}
...
esptool: error: argument operation: invalid choice: '-' (choose from 'load_ram', 'dump_mem', 'read_mem', 'write_mem', 'write_flash', 'run', 'image_info', 'make_image', 'elf2image', 'read_mac', 'chip_id', 'flash_id', 'read_flash_status', 'write_flash_status', 'read_flash', 'verify_flash', 'erase_flash', 'erase_region', 'version')

--port /dev/cu.SLAB_USBtoUART --baud 921600 --after no_reset write_flash --erase-all --flash_mode dio 0x00000 /Users/marcelstoer/Downloads/nodemcu-dev-17-modules-2019-02-10-13-23-19-float.bin
-p /dev/cu.SLAB_USBtoUART -b 921600 -a no_reset write_flash -e -fm dio 0x00000 /Users/marcelstoer/Downloads/nodemcu-dev-17-modules-2019-02-10-13-23-19-float.bin
--port /dev/cu.SLAB_USBtoUART --baud 921600 --after no_reset write_flash --flash_mode dio 0x00000 /Users/marcelstoer/Downloads/nodemcu-dev-17-modules-2019-02-10-13-23-19-float.bin --erase-all
--port /dev/cu.SLAB_USBtoUART --baud 921600 --after no_reset write_flash --flash_mode dio 0x00000 /Users/marcelstoer/Downloads/nodemcu-dev-17-modules-2019-02-10-13-23-19-float.bin

All of them work just fine on the CLI.

I haven't found a single combination yet that works when passed to main(...).

[projectgus]

Hi @marcelstoer ,

Do you have an example of how exactly you are calling main()?

Regarding the "big picture" for this, I consider calling esptool.main() under any circumstances a hack around esptool's poor Python API. I accepted PR #341 because this change makes it less of a terrible hack than the previous hack of editing the sys.argv list and then calling esptool.main().

The real problem (imo) is tracked in the venerable #208. I am hoping that before esptool v3.0 I get a chance to actually look into this, and we can have a proper story for how to use esptool from Python, can generate API docs, etc.

[projectgus]

(On the same note, I haven't looked closely at #402 yet but it looks like a good first set of steps on the path to breaking out main() into a set of callable module functions.)

[marcelstoer]

Do you have an example of how exactly you are calling main()?

Duh, I haven't actually studied how argparse.py works and simply assumed I can pass a string to main(). The absence of declared types in Python makes it a bit tough to read someone else's code for a non-Pythonista like me. Should have noted the code documentation mentions "...a list of ... strings"

command = ""

if not self._config.port.startswith(__auto_select__):
    command += "--port %s " % self._config.port

command += "--baud %s --after no_reset write_flash --flash_mode %s 0x00000 %s" % \
           (self._config.baud, self._config.mode, self._config.firmware_path)

if self._config.erase_before_flash:
    command += " --erase-all "

print("Command: %s\n" % command)

esptool.main(command)

I should be able to replace this with esptool.main(command.split(" ")).