Make esptool honor ESPTOOL/ESPPORT envvars (ESPTOOL-911)

[KaeLL]

Is your feature request related to a problem?

More like a nuisance. I use a script to setup my dev environment, a part of which is exporting the envvars for IDF, like IDF_TOOLS_PATH, IDF_CCACHE_ENABLE, and ESP{PORT,BAUD} depending on the project I'm working on. idf.py uses ESP{PORT,BAUD}, which saves me from ever having to care about it. That's not the same for when using esptool directly, and it scans my serial devices looking for the first one that matches unless I specify -p.

Describe the solution you'd like

When calling esptool, in the absence of -p or -b options, by default, have it check for the existence of ESP{PORT,BAUD} envvars and attempt to use them before falling back to probing the ports.

Describe alternatives you've considered

No response

Additional context

No response

[radimkarnis]

Hi @KaeLL,
esptool does exactly this and looks first for the ESPTOOL_PORT, ESPTOOL_BAUD, and ESPTOOL_CHIP env vars. More about this behavior is in the documentation.

[KaeLL]

I missed that. Thanks.
In any case, why 2 different sets of envvars for the same purpose between esptool and IDF?
Can they conflict if esptool is called by a idf.py wrapper?

[radimkarnis]

For historical reasons. Esptool has always been developed as a standalone app, not dependent on IDF, so it has its own set of env vars.

The env vars in IDF (ESPPORT, ESPBAUD) are passed by the build system onto the tools (esptool, idf_monitor, ...) as the --port and --baud command line arguments. So these take priority over the esptool-specific ones (ESPTOOL_PORT, ESPTOOL_BAUD). No clash should happen.

I guess esptool could honor the IDF-flavoured env vars as well in standalone mode. On the other hand, this could make things a little more confusing and we would break the rule of trying to keep esptool as independent of IDF as possible.
One more option is to make ESP-IDF build system set the esptool-flavoured ones as well when IDF-flavoured ones are set.

We will consider this request!

[KaeLL]

Esptool has always been developed as a standalone app, not dependent on IDF, so it has its own set of env vars.

Fair enough. Although "dependency" here is only materialized if either needed to change the meaning or purpose of these envvars, which I find highly unlikely. And it's not like esptool or IDF set these vars anyway, we do, which means that on top of being a fallback for the absence of command line options, they're also optional, which renders the relationship as weak as it can be.
Regardless, I originally had missed the fact that esptool already has its own vars, and it was for in case it didn't have these envvars. As that's not the case, the issue is pointless, so no need to bother with changing anything. I already changed my env setup script to define the ESPTOOL vars and moved on.

rule of trying to keep esptool as independent of IDF as possible

Even to the extent of redundancy? Because it seems to me the envvars are different just for the sake of being different.

Anyway, thanks for the clarification, and feel free to close the issue.