nixpkgs at present has two jekyll packages,
- Jekyll 3 in
rubyPackages, and - Jekyll 4 as a top-level package, built with
bundlerApp.
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 Gemfile.
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 bundix.
Does it make sense to package a Ruby gem like this in nixpkgs? Should it simply be pulled out?