github-pages environment should probably use the github-pages package

[l0b0]

pkgs.rubyPackages.github-pages is available, and includes Jekyll in a way that no longer requires .envrc or Gemfile for simple sites.

[Mic92]

Mhm with this package do we need a custom environment here anymore if nix-shell -p pkgs.rubyPackages.github-pages is enough? cc @anderslundstedt @sebtm

[SebTM]

I don't personally use the environment for github-pages, as there were only treewide updates in a time and there is a helpful alternative I would vote for removing them.

[anderslundstedt]

Mhm with this package do we need a custom environment here anymore if nix-shell -p pkgs.rubyPackages.github-pages is enough? cc @anderslundstedt @SebTM

The nixpkgs-22.11-darwin channel's pkgs.rubyPackages.github-pages does not build on Intel Macs. The unstable channel works though.

[SebTM]

So backporting it to 22.11 or waiting for next stable before remove would be an option?

[anderslundstedt]

Backporting is perhaps not worth it, since using github-pages from unstable works?

I just tried this shell.nix for some local GitHub Pages development:

with import <nixpkgs-unstable> {};
let
  github-pages-env = ruby_2_7.withPackages (ps : [ps.github-pages]);
in
stdenv.mkDerivation {
  name = "env";

  buildInputs = [
    github-pages-env
  ];
}

It was nice to not have to deal with bundle and the resulting speedup in loading the environment was very welcome, in particular when working with multiple local GitHub Pages developments. However, two issues:

(1) Symlinks in the repo that made it to _site/ (where they dangled) made jekyll --serve --watch crash on each first refresh. Did not have this problem before. (But I should really exclude these symlinks from _site, since they are just used for local development.)

(2) The resulting local environment above does not match the GitHub pages' server-side environment as well as the configuration resulting from installing github-pages via bundle does. For example: jekyll 3.9.2 instead of jekyll 3.9.3, github-pages 227 instead of github-pages 228. Also ruby 2.7.6 instead of ruby 2.7.4—but to fix this mismatch one needs to use ruby from an old channel, I guess.

In particular because of (2), for the purpose of debugging possible weird issues—where one suspects one's issue is due to the mismatch between the local configuration and the server-side configuration—perhaps keep (an updated version of) the existing environment (I should have time to update it quite soon, if desirable)¹ ? If so, then we should update the readme to indicate that their is a simpler solution that probably suffices in almost all, if not all, cases.

¹ Perhaps

https://pages.github.com/versions.json

can be used to automatically keep an GitHub pages environment up to date—but setting up such a solution is something I do not think I have time for (in particular given my somewhat limited nix competence).

[Mic92]

Now we should be able to switch to this.