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.

In reply to @ibizaman:matrix.org

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
infinisil: it seems that getting a google API key requires entering credit card information, which makes it not so easy to follow along with this:

In reply to @bzzm3r:matrix.org
what i'll do for now to follow the tutorial is change the map/geocode scripts so that they emit dummy information to stdout, rather than make actual API calls

In reply to @infinisil:matrix.org
bzm3r: Yeah it sucks a lot. We didn't have the resources to rewrite it into something more open

no worries at all, I'll submit a PR if I can something simpler.

I don't know much about open map APIs, so I want to be careful about not opening up another rabbithole...is there one that you recommend?

In reply to @infinisil:matrix.org
bzm3r: Yeah it sucks a lot. We didn't have the resources to rewrite it into something more open

no worries at all, I'll submit a PR if I can determine something simpler.

I don't know much about open map APIs, so I want to be careful about not opening up another rabbithole...is there one that you recommend?