In reply to @fricklerhandwerk:matrix.org

Things like at the top of this document: https://nixos.org/manual/nix/unstable/language/constructs/lookup-path

I don't want to call them grammar because we're still far away from actually formalising any of that

if we had a suitable "arithmetic" for "environment variable files", would we be able to replace env vars with such files? such an "arithmetic" i suppose would consist of operations like:

• merging two environment variables: most of the times, this will be an 'override' operation depending on the "type" of the environment variable (much like what happens in attribute sets, heh...oh wait...

okay, so with depending on the type of the environment variable (perhaps set by the user?) we'd have operations such as:

• overriding (i.e. where envVarA * envVarB == envVarB)
• concatenating (i.e. where envVarA * envVarB == envVarA + envVarB)
• structural(?) merging, i.e. where envVarA * envVarB == { A = envVarA; B = envVarB }
• list(?) merging, i.e. where envVarA * envVarB == [ envVarA envVarB ]

and these operations would help us "join" environments (attribute sets whose attributes are environment variables)?

okay, so with on the type of the environment variables (perhaps set by the user?) involved we'd have operations such as:

• overriding (i.e. where envVarA * envVarB == envVarB)
• concatenating (i.e. where envVarA * envVarB == envVarA + envVarB)
• structural(?) merging, i.e. where envVarA * envVarB == { A = envVarA; B = envVarB }
• list(?) merging, i.e. where envVarA * envVarB == [ envVarA envVarB ]

and these operations would help us "join" environments (attribute sets whose attributes are environment variables)?

okay, so with on the type of the environment variables (perhaps set by the user?) involved we'd have operations such as:

• overriding (i.e. where envVarA * envVarB == envVarB)
• string concatenation (i.e. where envVarA * envVarB == envVarA + envVarB)
• attribute set union, i.e. where envVarA * envVarB == { A = envVarA; B = envVarB }
• list concatenation, i.e. where envVarA * envVarB == [ envVarA envVarB ]

and these operations would help us "join" environments (attribute sets whose attributes are environment variables)?

okay, so with on the type of the environment variables (perhaps set by the user?) involved we'd have operations such as:

• overriding (i.e. where envVarA * envVarB == envVarB)
• string concatenation (i.e. where envVarA * envVarB == envVarA + envVarB)
• attribute set union, i.e. where envVarA * envVarB == { A = envVarA; B = envVarB }
• list concatenation, i.e. where envVarA * envVarB == [ envVarA envVarB ]

and these operations would help us "join" environments (attribute sets whose attributes are environment variables)?

I guess we'd also want similar parallels for other set-like operations: taking the differece, taking the intersection, etc. of "environments"

Welcome to the first year “Why?! And what if…“ deep dive!

Very briefly: historical reasons. Most of us weren’t around back then, but supposedly it was just the most straightforward way to do it. Stuff grew on top, and now it’s a system that’s hard to change without breaking lots of things.

There are discussions in the Nixpkgs Architecture Team about reworking stdenv, and Nix maintainers are talking on and off about which interfaces Nix itself should provide for that.

Generally: prototypes welcome! Just know that upstream tends to be quite conservative about such far-reaching changes because apart from requiring review they incur a maintenance cost someone has to be ready to carry, and that someone usually ends up being a very diverse group of people or no one at all. Therefore beyond just “but that’s obviously better” there is a coordination problem to be solved when it comes to changes to the core.

Here we’re more concerned with documenting what works, as it helps people to get things done right now. But it of course also exposes the warts more clearly and helps understanding what could be changed. Therefore, if you have any clarifications, please make small PRs with each of them. That makes it more likely to get each of them merged almost immediately, and those bits which need discussion (because often it’s not that simple) won’t block the ones that don’t.

In reply to @fricklerhandwerk:matrix.org

Welcome to the first year “Why?! And what if…“ deep dive!

Very briefly: historical reasons. Most of us weren’t around back then, but supposedly it was just the most straightforward way to do it. Stuff grew on top, and now it’s a system that’s hard to change without breaking lots of things.

There are discussions in the Nixpkgs Architecture Team about reworking stdenv, and Nix maintainers are talking on and off about which interfaces Nix itself should provide for that.

Generally: prototypes welcome! Just know that upstream tends to be quite conservative about such far-reaching changes because apart from requiring review they incur a maintenance cost someone has to be ready to carry, and that someone usually ends up being a very diverse group of people or no one at all. Therefore beyond just “but that’s obviously better” there is a coordination problem to be solved when it comes to changes to the core.

Here we’re more concerned with documenting what works, as it helps people to get things done right now. But it of course also exposes the warts more clearly and helps understanding what could be changed. Therefore, if you have any clarifications, please make small PRs with each of them. That makes it more likely to get each of them merged almost immediately, and those bits which need discussion (because often it’s not that simple) won’t block the ones that don’t.

🤣 makes sense! So I'll take it as "my understanding is roughly correct", and to bring it back to documentation alone:

1. I'll submit some small PRs to improve various small things around the parts of the stdenv docs I have just finished reading.

2. Voicing out the above (and receiving some feedback on it) helps me make sure I'm not misunderstanding things to the point where the documentation changes are misguided.

3. And I think I did have a misunderstanding. When I woke up today morning, I realized that: actually, stdenv does use attribute sets precisely to manage/merge environment variables.

Nix expressions don't transfer environment variables "raw" between themselves. Instead, the environment is captured within attribute sets (this is why extra attributes within the arguments passed between stdenv functions are eventually "realized" as environment variables).

Computations regarding what environment variables are ultimately needed during a derivation's build-time (or its run-time) happen with these attribute sets: for example, this is what mkShell does), while functions such as shellHook serve the role of the "functor" I was imagining: they convert these attribute sets into environment variables.