Unable to inherit cargo CLI args

[TheButlah]

Most cargo commands seem to accept their arguments after cargo's arguments, via -- (or vice versa, accepting cargo arguments after --). This program doesn't - a consequence of this is that I don't appear able to pass --no-default-features to control the cargo build.

[jessebraham]

So I've been thinking about this for awhile, and I'm not entirely sure how I would like to proceed with this. The way I see things there are three potential paths forward for this, each with their own advantages and disadvantages.

1. Do not forward any arguments to cargo; all arguments are defined by cargo-espflash instead
   • This is our current approach
   • PRO: This does not change our current call API in any breaking way
   • PRO: This gives us complete control over which options are being set at build time
   • CON: This is less flexible, and requires modifying the source code in order to add support for additional options
2. Only pass cargo arguments via forwarding; do not define any arguments for cargo in cargo-espflash
   • PRO: All cargo features are automatically supported by cargo-espflash
   • CON: This may make the call API a bit unpleasant to use, as it might not always be clear which position an argument should be in; an example invocation:

     • $ cargo espflash --format=direct-boot --monitor -- --example=hello_world --features=direct-boot --release

3. Define arguments in cargo-espflash while also allowing forwarding of cargo arguments
   • PRO: This does not change our current call API, yet still allows for people to use features which we don't explicitly cover
   • CON: It's possible to provide some option twice, so we need to either merge the setting or override them when this occurs
   • CON: This results in a fairly confusing call API (IMO)

Nothing really actionable from what I've said here, mostly just a brain dump. If you have any input please let me know, otherwise I'll continue trying to decide on which approach is the best.

[jessebraham]

Given that there's been no activity here, and there's no clear path forward, I'm going to close this as "won't do", sorry about that.

Maybe in the future if there's a 3.0.0 release we can rework this, but we don't really have the resources to tackle this now and I'd like to finally get a release out as soon as possible.