config VS cargo-xtask

I actually quite like the config, seems intuitive! Though, I am comparing it to this abomination, so I might have low expectations here :-)

4) For scripts you put for everyday use in ~/bin, I've found busybox style multipurpose binary invaluable. You put all your scripts into a single Rust binary, and than hard-link this binary under different names in PATH, so that the first argv is actually the name of subcommand. Here's how the infra works for my scripts, and here's an example script.

1) Invest into application-level profiling, using tracing::span! for collection and something like tracing_tracy or tracing_span_tree for visualization. This should give you high-level logical profile. 2) If on Linux, learn a bare minimum of perf for collecting data (the extent of my knowledge about perf is basically this script https://github.com/matklad/config/blob/master/tool/src/prf.rs). Use neither flamegraph.pl nor cargo flamegraph for visualization, use https://profiler.firefox.com/ instead.

And, while a spam links, here’s a link with more links: https://github.com/matklad/config/blob/master/links.adoc

💡 Inspired by matklad/cargo-xtask and based on 🏃‍♂️ Write your Rust project scripts in task.rs from the Rust ecosystem.

Using a cargo-xtask task to generate them as a manual step (inlyne currently does this)

As someone else said just is good for that job, or you could implement an xtask helper for these things and setup a suitable development environment with that: https://github.com/matklad/cargo-xtask/

Well tools like cornucopia, prisma-rust-client, protoc-gen-tonic, they don't generate in build.rs, but instead provide either a cli to be called ahead of time, or provide a library that can be called by your own binary (which should generally follow the xtask pattern)

If I understand, this is a tool for when working on the project itself? Akin to a helper script? You could go the cargo install route as already pointed out but there is also the xtask convention.

For simple cli apps for internal use, such as cargo-xtasks, I prefer pico_args due to its fast compile times.

For developer-oriented stuff, there's tools like xshell and cargo-xtask. For operator tasks that need to run in a deployed environment, it's not usually a big lift to add CLI subcommands to your binary. It's certainly more boilerplate and inertia than doing stuff in a live REPL, though, and sometimes difficult to recommend for truly one-off situations.