2023-04-13 - Learning Journey Working Group - Meeting Notes #4

2023-04-13 - Learning Journey Working Group - Meeting Notes #4


  • Previous action items
  • Closing the loop on the nix-shell -p tutorial
  • Drafting an outline for the shell.nix tutorial


Action items

1 Like

This. I thought we converged on the example last time. The advantage of specifying a release explicitly gets us close to a habit of actually pinning things. A release channel does not change that much.

@Infinisil can you chime in, I’m still fuzzy on the details because it appears my particular Nix setup is non-standard.

I’m now thinking we should not use channel:nixpkgs-unstable, because it depends on special URLs and channels.nixos.com, which won’t be a requirement for pinning.

Instead I think we should go for fetchTarball "https://github.com/NixOS/nixpkgs/tarball/nixpkgs-unstable", which only needs GitHub knowledge and leads very well into pinning.

In sequence:

  • Introduce nix-shell -p without explicitly specifying where nixpkgs comes from, underneath nix-shell just accesses <nixpkgs>, which works in any installation.
  • Introduce a shell.nix that copies the nix-shell -p behavior exactly by using <nixpkgs>, explain how <nixpkgs> is provided impurely by the system installation of Nix
  • Change the shell.nix to use fetchTarball "https://github.com/NixOS/nixpkgs/tarball/nixpkgs-unstable" instead of <nixpkgs>, showing how this removes the system installation impurity, replacing it with an evaluation impurity (because the nixpkgs-unstable branch changes every so often). We don’t need to go into details as to when the branch updates.
  • For the pinning tutorial we can then initially just replace nixpkgs-unstable with a git revision, manually at first

@zmitchell The difference between a standard installation and a flake-only installation is that:

  • A standard installation sets up a default channel using nix-channel and adds a NIX_PATH entry for it. <nixpkgs> will then point to the fetched channel. Channel updates can then be managed using nix-channel --update
  • A flake-only installation however doesn’t really need a NIX_PATH, since everything should be done via Flakes, so nix flake update is used to update Nixpkgs instead. But for backwards compatibility, <nixpkgs> will still point to a Nixpkgs version (though fetched with Flakes). This also makes nix-shell -p still work (because internally it uses <nixpkgs>).

I agree with the general proposal, but why would you point to unstable? That is going to change quite rapidly and will tend to produce broken examples. With a release branch we at least have a good chance of avoiding inscrutable surprises for beginners.

Good point, release branch sounds better, though it shouldn’t be release-22.11 (that’s where PR’s go directly), but rather nixos-22.11 (that’s only updated when Hydra checked that the PR’s didn’t break anything)