RFC: One binary vs multiple smaller tools

[bjoernQ]

There are ideas to extend the functionality beyond just creating a project, e.g.

• "edit" the configuration options of an existing project via a TUI
• collecting diagnostic information for troubleshooting
• ...

There are generally two ways to go forward

• have one binary (named more general) to do all of that and more in future
• have multiple binaries specialized for the job (e.g. esp-generate, esp-config, esp-diag ...)

[bugadani]

My vote is on a single binary, with multiple subcommands, something like:

• esp-rs new-project / esp-rs generate
• esp-rs configure
• esp-rs report
• ...

My main argument is that users need to install a single tool, and they can simply review their options with esp-rs --help. Keeping a single binary also means it's unambiguous what tool comes from which crate - i.e. the "Do I need to also update X?" question will be simpler to answer(, especially if we would integrate cargo-espflash into this tool 👀)

[SergioGasquez]

If we go for the single binary approach, do we also include other tools like espflash and espup?

[bjoernQ]

If we go for the single binary approach, do we also include other tools like espflash and espup?

Good question - where to draw the line 🤔

[jessebraham]

If we go for the single binary approach, do we also include other tools like espflash ...

I would really rather not.

[bjoernQ]

I would really rather not.

Was my immediate reaction, too. But it made me think of idf.py and how it's mostly a wrapper for other things like esptool.py - which would be a third option - but maybe not

[bjoernQ]

After letting this sit for some time I'd vote for single binaries but moving esp-config CLI to another repo, rename it and publish it as its own binary crate.

• It shares absolutely nothing with esp-generate and more important: it won't need updates tied to esp-generate's release cycle.
• We can still change our mind and fuse everything together into such a "super tool" (might it be a wrapper like idf.py or everything baked together doesn't matter)
• if we would aim for the "super tool": where to draw the line? how should users understand why some totally unrelated things are found in that "super tool" and others are separate
• we can add checks for more tools to esp-generate easily - and that will probably increase those tools discoverability
• we already need to teach users about various tools - a few more or less isn't much of a problem

"esp-config" was more like a working title and for multiple reasons it's not a good name

In lack of ideas here are some ideas from ChatGPT

🛠️ More Functional & Clear Suggestions
General
espcfg — very compact; common pattern in Unix tools (cfg = config)

espconfig — full word, easy to understand, no ambiguity

espsetup — implies initial or ongoing configuration

espinit — good if the tool is used to initialize config

esp-tool — generic but versatile and clear

espmanager — descriptive, though a bit long

esp-settings — verbose but self-explanatory

If it's CLI-focused or low-level:
espctl — “ESP control,” a very Unixy naming convention

espadm — like useradm or sysadm; "administrator" for ESP configs

espconfctl — long but very specific: "ESP configuration control"

espsetupctl — if you like extremely descriptive CLI patterns

Rust-optional but useful:
esp-proj — emphasizes project-level settings

espconfig-cli — clearly a command-line tool for ESP config

esp-tweak — more casual, but still clear

The only thing on that list I might like would be esp-tweak but ... I guess we can do better