config-rs VS cargo-xtask

I like config.rs, but I am struggling to overwrite config profiles with environment variables. The desired config is mixed, like .toml

Consider config crate. It could be like:

I've been using Config most of the time. I also use once_cell to make it a static variable.

I've enjoyed using this one: https://crates.io/crates/config

Anyone know of a library like https://github.com/netflix/go-env but for rust? I found https://github.com/mehcode/config-rs but it's just not as simple...

I was just in that space today. The config crate has an example you might find useful: https://github.com/mehcode/config-rs/tree/master/examples/hierarchical-env

How it differs from config?

Checking an environment variable is very easy with std::env::var or similar. If you have other bits of configuration that also change—which is typical; things like DB connection strings—you may consider a more full-featured solution like https://docs.rs/config/0.10.1/config/ (pay particular attention to this example, which seems to be very close to what you want: https://github.com/mehcode/config-rs/blob/master/examples/hierarchical-env/src/settings.rs ).

It's unfortunate, it looks like there was an attempt to get someone else to maintain it here, but no one ended up really stepping up to the plate.

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