rustic VS cargo-xtask

I'm a huge fan of restic as well. My only complaint is performance and memory usage. I'm looking forward to being able to use Rustic: https://rustic.cli.rs/

Since this is HN, we also need to mention [Rustic](https://github.com/rustic-rs/rustic) which is better since it's in Rust.

For anyone just passing by, from the rustic website[0]:

> Stability: Currently our tools are in beta state and miss regression tests. It is not recommended to use them in production backups, yet.

[0]: https://rustic.cli.rs/

After a bit of refactoring, we are very proud to announce the first version of rustic_core, a library providing all functionality available in rustic, see https://www.reddit.com/r/rust/comments/12xs8h3/announcing_rustic_fast_encrypted_deduplicated/. In fact, rustic is now just a thin CLI wrapper around rustic_core.

There is support to extend a local repository using e.g. the par2 tool, see https://github.com/rustic-rs/rustic/blob/main/examples/par2.toml But for recovery, that would involve manually recovery of broken repository files.

💡 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.