Builds and shell builds the whole of nix for its manual

[samueldr]

This nix is ending up building nix in its entirety only for the nix manuals.

Can short-circuit the whole build and build only the manual rather than the whole tool? Makes for a slow ramp-up when hacking on the homepage, using nix-shell.

• https://logs.nix.samueldr.com/nixos-chat/2020-07-02#1593718244-1593718632;

cc: @ixxie who reported on IRC

[nixinator]

Seems the flake is now tracking the latest release. which was done here

25a22e0

Besides that, the flake.lock file is being updated by a GitHub Actions Bot, so it's tracking the cutting (bleeding) edge, stuff that has not been built by hydra yet and cached on cache.nixos.org.

so nix is doing exactly what is supposed to do!!! :-) ...

Work around...

git checkout 25a22e0

nix-shell

i guess the main thing is should the master branch tracking the bleeding edge builds? or stable?

Perhaps a 'branch of bleeding edge' might be needed, or the flake.lock get updated a little be slower so hydra has time to cache it?

[samueldr]

I believe it may happen that a specific revision ends up not being cached for small whiles.

The nix:maintenance-2.3 jobset uses the -small channel, which is not updated in lockstep with the not-small equivalent channel.

Though, there is one little caveat, I am not sure that with flakes github:* is equivalent to Git checkout in Hydra. If it isn't, it would never be cached due to it being a different input.

So in the end, having a short-circuited build that only builds the manual is still worthwhile.

[garbas]

• latest-release of Nix is actually latest stable release. Nix only has one "channel" and a separate repository like nixpkgs-channels would be an overkill. This was added so that we don't have to update homepage for each nix release.

I can see two things to improve current situation:

1. Completely automate the release of nix (as is done with nixpkgs).

   I think currently the upload_release.pl script is still called manually (I'm not 100% on this). It would be great if this would be automated and merge to latest-release would only happen when everything is green on hydra and when there is binary cache.

2. Separate build Nix manual from Nix

   At this point we might see if Nix is actually needed to build the manual. It might be separated away and provide a smaller closure when things go wrong and cache is not there, like in this case.

I don't see the solution happening in nixos-homepage repo, but actually within Nix release.nix or improving general release process of Nix.

@edolstra Would above suggestions to improve be OK to implement for Nix?

[edolstra]

It sounds like a lot of work to speed up the nixos-homepage build a little bit. And most of the time the nix package used by nixos-homepage should be in the binary cache anyway.