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.