support nix environments

[jdx]

we should have similar support to direnv's use nix feature. Perhaps something like this:

[env]
"@nix" = "default.nix"
"@nix:flake" = "flake.nix"

I noticed https://github.com/nix-community/nix-direnv but only briefly glanced at it. Might be worth seeing if I can port similar performance considerations.

[jdx]

this is definitely something I could use a hand with if someone wanted to contribute. I don't use nix or understand it that well. I can help out with the rtx side of this if someone else could basically just make a script that exported the proper env vars (as of right now it isn't possible to do the @nix thing in the [env] section but that's something I can pretty easily add). You could come chat with me in the discord if you want to go over it with me.

[MatrixManAtYrService]

Some doubt about how direnv does it

I've spent a while using nix devshells (as defined in a flake.nix and activated via direnv's use flake). I've been doing this to encapsulate my entire projects' dev tooling. Ever since I encountered this bit of wisdom I've been questioning whether its a good idea.

The suggestion is that devshells are for debugging nix derivations, not necessarily for every little thing related to that project. So I think it would be nice if a flake could define a devshell separately from a list of packages mise would provide. This is a departure from direnv which just wants a shell to use.

How I'd do it

I made a gist with an example of how this might look: https://gist.github.com/MatrixManAtYrService/2e661cc9b7205e05da92de1778545a53 In this contrived example, pokemonsay and bb are tools that mise might be configured to provide, and cowsay belongs in exclusively in nix shell for use debugging strictly nix stuff.

Notice that the devshell PATH includes stuff like gnused, which came along for the ride when we asked for cowsay. By contrast, the references listed under the mise package only include the two that we asked for. I think that including less via mise means fewer opportunities for surprise interactions between one package's build inputs and another package's behavior at runtime. Problems like this are uncommon, but I find them hard to debug.

So I proposing that in addition to letting users indicate a devshell to mise, we also teach mise to accept packages from a flake definition, this way developers can package tools for their own consumption in a way that mirrors how they might package them for their user's consumption.

---

Lets do it?

I'm not a rust dev, and I just ran across mise today, but I'll help with this if I can because I'd probably use it often. The gist :point_up: should give you a feel for how we might go about populating the nix store and getting the paths we need.

To ensure my ideas here aren't totally crazy, I've consulted the nix forum for a sanity check on this idea. So far, signs point to not crazy.

[MatrixManAtYrService]

• I need to study https://github.com/chadac/mise-nix to see if it scratches this itch already.

• After a conversation in discord, I got this feedback:

I feel like what would be challenging is mise needs to know what the bin names of all the tools are

I feel like https://nix.dev/manual/nix/2.18/command-ref/new-cli/nix3-run.html#apps could be used to solve this, but I need to spend some time tinkering before I have a proposal for precisely how.

• Another comment from discord:

I think @MatrixManAtYrService's approach is more similar to integrating with something like poetry

I'll also take a look at how mise integrates with poetry. I've got homework to do. I'll be back....

[fricklerhandwerk]

[env]
"@nix" = "default.nix"
"@nix:flake" = "flake.nix"

A robust interface would at least allow specifying which attribute you want from the Nix expression, and what to do with that. Is it supposed to merely be a tree with stuff in it (such as the output of buildEnv) or something that produces a particular executable that will be run, such as a shell invocation?