nixpkgs at present has two jekyll packages,
- Jekyll 3 in
- Jekyll 4 as a top-level package, built with
Since Ruby 3,
jekyll serve requires the
webrick gem (upstream issue #752) which is not in nixpkgs.
While trying to fix both packages in nixpkgs, I realised that situation with Jekyll in nixpkgs is a bit of a mess beyond just needing webrick.
Packaging Jekyll with
bundlerApp makes the program very inflexible for the user, because they cannot override the
Gemfile. It appears that most users use
bundlerEnv with their own
Jekyll 3 is not at end of life, and still gets patch (in the semver sense) releases, and there is currently no mechanism or precedent for having multiple versions of a gem in nixpkgs.
Ruby gems in
pkgs/top-level/ruby-packages.nix have to be, as far as I can tell, added by hand, along with all their dependencies. This is the part where using Jekyll through nixpkgs (as opposed to using
bundlerEnv) seems to give negative value for end users: if they want an optional Jekyll dependency, plugin, or theme that is not already in nixpkgs, they have to either add it to nixpkgs on a branch, or define a Nix derivation for the gem and pass it in to
ruby.withPackages, rather than simply adding it to their Jekyll project’s
Gemfile, and re-generating the
gemset.nix file with
Does it make sense to package a Ruby gem like this in nixpkgs? Should it simply be pulled out?