https://clever-cloud.com/blog/features/2018/02/13/issues-helper/
I wrote GLI to facilitate opening issues on gitlab and github
In my position (small team, flat hierarchy, limited resources), creating tools is the best way to make a process stick.
I can't enforce documentation, mistakes are made, people can be tired.
Also, a process that cannot be enforced with a tool is probably too complex: it's a sign that it may require more thought.
Know when things should stay manual. Preferably, keep things manual a bit before writing code get a feel of the different scenari
internal tools should not be shitty. If you're not the only one using it, then you should be extra careful to clean it up before sharing it being consistent is hard in general, and some tools make it extra hard a proper set of tools will help you a lot.
very frustrating to wait for a program to start (eg when all it will do is display help)
Try to minimise hidden dependencies, avoid requiring a complex environment to run
terrible for argument handling not that portable, very fragile
I could go on and on, please don't ask me "why not go?" we can discuss it later if you want. I don't want to say mean things while being recorded.
most important thing: I'm happy when I use it. No warmup, standalone binaries. Not as easy to tweak as bash scripts tho. So you need to know a bit more what you want to do and where are the moving parts
clap is the de-facto lib for cli params handling in rust
Easy to split things between a binary project and a library project It allows to reuse logic outside of the binary, or to have multiple binaries depending on the same modules. You can even target web assembly and ship to the browser
Let's see some tools… in action
Une fois j'ai zappé un talk que je donnais. Et du coup c'était pas gentil pour @aheritier. Je vais faire un outil pour ne plus oublier mes talks
The devoxx CFP provides an API to browse talks and speaker info, let's write a simple program which reads it
# Please use a proper
#rustup package if possible
curl https://sh.rustup.rs -sSf | sh
rustup update
# Not mandatory, but better
rustup component add rls-preview \
rust-analysis \
rust-src
rustup component add rustfmt-preview
# VSCode support
ext install rust Rustup: cargo (build tool & rust compiler) <- allows to have different versions at the same time Components: RLS (IDE-like tooling), rustfmt VSCode: has good rust support. IntelliJ is ok as well (I heard)
cargo new devoxx-rust --vcs git
cd devoxx-rust
cargo run
Running the program without arguments (or configuration) should not do anything irreversible Either display help or display a friendly message explaining what to do before using it
There are old school man afficionados, but properly integrating with man is quite complex if you don't go through proper distro packaging.
--help support When I use a new CLI tool, I either run it without arguments or with --help Both cases should be handled well, and not run scary errors.
Except for very old commands like tar, try to stay consistent with modern practices
-s and --long-name Flags / options are for optional / contextual parameters. Consider using arguments instead (even though they do improve readability)
Hardest part is to ship it.
cargo install for rust users Quite easy to just ship binaries for others Integration in distros is not too complicated as well