Drop explanations on "classical" nix?

[blaggacao]

A couple of code examples make use of classical nix, such as import <nixpkgs>.

Since it's already hard to teach nix, it's probably even harder to teach a mixed syntax.

Don't have a strong opinion, this just jumped to my eyes, while flying over the text.

[jonringer]

Yes, but creating a flake.nix and related construction is also very distracting from trying to teach the objective.

It would be.... ~10 lines of flake.nix to just replace import <nixpkgs> {};

[nrdxp]

Right, but on the flip side, import <nixpkgs> {} is fairly bad practice in most situations, and now is our chance to set off new comers into defining good habits

Eelco, at least, wants to stabalize flakes fairly soon, so I think it would help immensely to simply just target flakes as the "blessed" path

[jonringer]

I agree?

flake.nix is more about exporting a project to be able to be consumed by others, but it also means that it needs to encapsulate all of that complexity. For the purposes of simple scripts, it's a lot to define nixpkgs, import it, create a nix expression, then call it.

I could add another "flakes primer" in which we create an example flake.nix. I would just like to keep the "prerequisites" to a minimum. Assuming content from another section also has a cognitive cost for learning, and I don't want it to quickly overwhelm the reader.

[jonringer]

Part of me also feels like the usage of import <nixpkgs> {} could help transition into why flakes are necessary.

After the "build a Nix package" section, we can introduce flakes, and the code examples can transition into make that code flakified.

[nrdxp]

we could, alternatively, also just provide a bunch of flake templates in this repository so users can just run nix flake init to get the code, bypassing the boilerplate.

instead of import <nixpkgs> {} upfront, we could do explicit pinning, like nixpkgs = fetchurl .... My only fear with introducing <nixpkgs> first is that some users may take that as the first thing they see, and just run with it.

It might be a more natural transition from explicit pinning to flakes anyway, since its just, "oh okay, so the flake is just doing the pinning for me under the hood."

We are obviously gonna have to explain the NIX_PATH either way, but I would like do so in a context where it's already been firmly established that using it defeats a lot of the purpose of why one would want to use nix in the first place.

I tried to offer some explanation of this already elsewhere:
https://github.com/divnix/flake-bootstrap

Though I haven't worked on that repo since I initially started it.

edit
There is also the new repl-flake experimental feature which just treats arguments to nix repl as flake refs instead of file names, so we could even provide predifined repl environments for book readers as well to help with flake boilerplate, assuming this is also stabailized when flakes are.

[jonringer]

We are obviously gonna have to explain the NIX_PATH either way, but I would like do so in a context where it's already been firmly established that using it defeats a lot of the purpose of why one would want to use nix in the first place.

Fair, but I'm not opposed to hand waving and just saying, "don't worry about this for now". Nix requires you to bite off a lot

[blaggacao]

I know that @manveru has a habit of defining simple scripts with builtins.getFlake, maybe that is a route to go... (together with the standard repl)

[nrdxp]

Today as I was grepping through the nix commit log I just so happen to come across this little gem as well:
NixOS/nix@62a6eeb

This might allow us to explain the NIX_PATH while still writing code samples that are reproducible

[blaggacao]

Hm, wouldn't then bultins.getFlake "github:nixos/nixpkgs" still be a better shorthand? It takes the magic aliasing out of the game.

[jonringer]

Hm, wouldn't then bultins.getFlake "github:nixos/nixpkgs" still be a better shorthand? It takes the magic aliasing out of the game.

Yea, I guess that's pretty similar to <nixpkgs>. I'm not opposed :)

[nrdxp]

Both require --impure so I feel the <nixpkgs> actually has a slight advantage in that it is shorter

[jonringer]

Both require --impure so I feel the actually has a slight advantage in that it is shorter

Yea, but it's more likely to "stand the test of time". As <nixpkgs> can be viewed as "deprecated"