Describe the feature you want
What
Quoting the chat with minor edits:
I've been considering to develop "UAD-NG: CLI edition" (the name can be shortened to "UAD-CLI", as the legacy UAD didn't have a command-line interface).
Thanks to clap, this could be easy. I could even implement #184 while we're at it
I don't have time for this, but I wish to see it happen.
clap may conflict with iced, and the CLI is supposed to be "lite"
How
I thought a separate repo (on my account, and then later on the org) was a good idea, but @schbrns suggested that it might be better to take the mono-repo approach, as there's some internal code that can be shared between GUI and CLI (such as the handling of ADB commands, and the logic for different Android versions).
It's possible to convert to a mono-repo, there are 3 ways:
It seems workspaces are the most sensible option, as multi-crate would require us to have 3 crates (is this 100% true?):
- core library
- GUI importing core
- CLI importing core
Why?
CLIs tend to be more accessible (#605) and reliable (#645) than GUIs. This would allow more potential users to use the app with minimal problems.
The CLI can be designed to be more similar to a typical package manager, which could make it more intuitive and safe (#642) to use than the GUI.
Also, the CLI wouldn't need as much logging as the GUI (shells write to a .*_history file), which would make it even more efficient.
why not TUI?
Because that's just a GUI made of text, it's a waste of time. CLI and GUI complement each other.
Drawbacks
If we do design it as a typical pack-man, we would need to somehow cache the list of installed packs from every connected device, as a command such as uad ls -i (list installed packs, rather than the pack-IDs in uad_lists.json) could take hundreds of milliseconds to sync.
Rather than caching to storage, a REPL might be a better choice, as the state of the session is always in memory.
etc...
We may have to revert #154
Acknowledgements
Describe the feature you want
What
Quoting the chat with minor edits:
How
I thought a separate repo (on my account, and then later on the org) was a good idea, but @schbrns suggested that it might be better to take the mono-repo approach, as there's some internal code that can be shared between GUI and CLI (such as the handling of ADB commands, and the logic for different Android versions).
It's possible to convert to a mono-repo, there are 3 ways:
b3sumdoes.hxdoes.It seems workspaces are the most sensible option, as multi-crate would require us to have 3 crates (is this 100% true?):
Why?
CLIs tend to be more accessible (#605) and reliable (#645) than GUIs. This would allow more potential users to use the app with minimal problems.
The CLI can be designed to be more similar to a typical package manager, which could make it more intuitive and safe (#642) to use than the GUI.
Also, the CLI wouldn't need as much logging as the GUI (shells write to a
.*_historyfile), which would make it even more efficient.Because that's just a GUI made of text, it's a waste of time. CLI and GUI complement each other.
Drawbacks
If we do design it as a typical pack-man, we would need to somehow cache the list of installed packs from every connected device, as a command such as
uad ls -i(list installed packs, rather than the pack-IDs inuad_lists.json) could take hundreds of milliseconds to sync.Rather than caching to storage, a REPL might be a better choice, as the state of the session is always in memory.
etc...
We may have to revert #154
Acknowledgements