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.

In reply to @bzzm3r:matrix.org

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

Hi everyone. Thank you for all your efforts on the nix documentation. It is really a treasure trove of information that I use just about all the time.

I tried using `nixos-render-docs` on my project’s manual. I was lured away from nvmd thanks to this new tool able to parse markdown files instead. But then I stumbled into a few issues. One is about embedding pictures from nested directories. I’ll create an issue and test and PR soon about that one.

I did create an issue about the main blocking one for me https://github.com/NixOS/nixpkgs/issues/272329.

I just started looking at that tool’s code and it’s still not obvious to me how all works together to create html files. But if you deem solving this issue in the tool worth it, I’m happy to invest some time on this.  

In reply to @bzzm3r:matrix.org
(It has, for me at least, been very helpful in understanding what mkShell does, so that I can write my own derivation that is less bash-focused, as Rob suggests in the SO answer I linked before: https://stackoverflow.com/questions/71016402/how-to-start-a-zsh-shell-session-with-additional-non-permanent-aliases/71112117#71112117) (Side-benefit: I don't have to use direnv. I could probably submit this little project---once completed---as a guide/recipe on nix.dev...)

Extra attributes being passed as environment variables to the builder executable is a behavior of the underlying builtins.derivation: https://nixos.org/manual/nix/unstable/language/derivations#builder-execution

And while mkShell is quite magical, it essentially is also just a wrapper around the undocumented buildEnv.