direnv VS naersk

I also made the export diff configurable, motivated by this post: https://github.com/direnv/direnv/pull/1233

Nice.

For years I've been using [direnv](https://direnv.net/) for this, setting environment variables which git picks up. This looks like a more feature complete equivalent, although to be honest I only really need switching of committer email and the SSH key used.

Direnv, for the uninitiated, loads and unloads environment variables when directories are entered and exited. Under every project folder there is a `$PROJ_DIR/.envrc` which contains:

buffer-env: A pure-Elisp version of the direnv utility. Useful to make Emacs aware of Python virtualenvs (which, judging by the questions posted here, is unfortunately still a complication for a lot of people). Similar to (and inspired by) envrc, but doesn't require the direnv program.

You can look at direnv to see this in action as they wrote shell hooks that get loaded into the shell profile and are executed on every prompt. https://direnv.net/

Yes, most Nix users employ https://direnv.net or the equivalent for your IDE of choice. Emacs for instance has https://github.com/purcell/envrc which set per-buffer variables.

The more applications I write, the more I tend to avoid typical config files in favor of using direnv [0] to set environment variables.

[0] https://direnv.net/

i would also recommend using crane or naersk since iirc rustPlaform.buildRustPackage can mangle some of these options (or maybe i just did something wrong lol)

Have a look at naersk, it neither requires generated Nix files nor IFD.

We use naersk[0] for Rust projects in our Nix monorepo (for example [1]). It's pretty hands-off in terms of the Nix code needed (you don't need to pin hashes inside of the Nix code as long as you have a Cargo lockfile) and all the existing tooling keeps working fine.

The main drawback of it is that it currently builds all of your dependencies in one big derivation, so any dependency changes cause a full rebuild. There's some other project I saw fly by which attempts to do a similar thing but split each crate into a separate derivation, but I forgot what it's called and have no experience with it.

[0]: https://github.com/nix-community/naersk

[1]: https://cs.tvl.fyi/depot/-/blob/ops/journaldriver/default.ni...

You can also use naersk¹ if you want to avoid a two-step process. It's especially convenient when using nix flakes.

¹https://github.com/nix-community/naersk

I created https://github.com/nmattia/napalm/issues/34 and https://github.com/nmattia/naersk/issues/183 to move them to nix-community

sounds exactly like what naersk does. naersk doesn't need a cargSha256 argument since it downloads dependencies from Cargo.lock. it can also grab the version number from Cargo.toml