Add checks, nodejs, fourmolu-0.14

chris-martin commented 1 year ago

This adds nodejs versions 16.20.{0, 1, 2}.

Also bumped the default fourmolu from 0.13.0 to 0.13.1, and added 0.14.0 (though it is not yet set as the default).

I've also just learned about how to write flake tests (aka "checks"). To run the checks from the root of the repo:

$ nix flake check ./main

Probably this should run in CI, but I haven't looked into it yet.

Each of the packages provided by this flake now has a check that runs the provided executable with the --version option and asserts that the version number is what we expect. This accomplishes two things:

It's a very basic check that the package actually builds and produces a working executable
For packages "re-exported" from nixpkgs, it's useful to assert that our flake is actually providing the version that it claims to be providing. For example, the definition nodejs-16-20-2 = nixpkgs.stable.nodejs_16; is fragile in that nixpkgs might bump the version, and then if we upgrade stable it would no longer be 16.20.2. Now that it is tested, when we upgrade the flake inputs we can run the checks, and if needed we can hold back the version of nixpkgs that we get that nodejs package from.

An example of holding back nixpkgs for a specific package can be seen in this PR. I did it for fourmolu, not because getting fourmolu from the latest version of the stable channel wouldn't work, but simply because I didn't want to trigger a long recompile. It is good to keep things following the head of a release branch, but some of the builds are too slow to be upgrading things higgledy-piggledy until we have some binary caching infrastructure in place.

I've adopted here a new convention for naming the nixpkgs flake inputs that don't simply follow a branch head. Previously I was naming them based on the reason I wanted a specific old revision (e.g. ghc927). Here I'm naming them as a combination of the branch name and commit date: nixpkgs-stable-2023-07-25, nixpkgs-master-2023-05-06, nixpkgs-master-2023-07-18. For one thing, I want to be able to easily see how old something old is. But the main motivation is that I want to be able to minimize the number of nixpkgs flake inputs. The more versions of nixpkgs we have in use simultaneously, the more chances there are that we end up redundantly building slightly different versions of things. And so when searching back in nixpkgs history for a version that has some particular thing I'm looking for, it's good to be able to connect the timeline to the set of nixpkgs revisions we already have pinned, to try reusing an existing input if possible rather than adding a new one.

Running the nix flake check command revealed something I didn't know, which is that the nix tooling expects a flake's packages to be a flat, not nested, attribute set. So unfortunately I already need to make a change to what I just did earlier today, which is e.g. fourmolu.v0-13 is being renamed to fourmolu-0-13 (no dot).

chris-martin commented 1 year ago

Okay, that was actually really easy to set up. It'll be building for a while, though. I guess we'll find out tomorrow whether it passed.

chris-martin commented 1 year ago

CI caught a mistake already :smile:

freckle / flakes

Add checks, nodejs, fourmolu-0.14 #3