Add support for building Bashcov with the Nix package manager

[tomeon]

trafficstars

Relates to #72 .

This branch introduces support for building Bashcov with Nix. My hope is that some of this code can be downstreamed to Nixpkgs to satisfy NixOS/nixpkgs#242854. In the meantime, the changes in this PR permit Nix users to incorporate Bashcov into their Nix environments / NixOS configurations by using either Nix flakes or legacy Nix code-fetching methods.

Additionally, this PR introduces a Nix-based development environment that can be entered by executing nix develop from within the repository. This development environment includes Ruby 3.2, plus bundix for helping to maintain the gemset.nix file that acts as a gem specification for consumption by the Nix bundlerEnv Bundler environment builder.

I plan to add support for executing Nix builds and tests within the GitHub actions workflow introduced in #76.

TODO

• [x] Add Nix flake check to GItHub actions workflow.
• [x] Developer documentation (how to enter the Nix development shell, how to update gemset.nix, ...).
• [x] Consumer documentation (how to install Bashcov using Nix flakes).
• [x] Sanity checks (e.g. CI test and/or pre-commit hook verifying that gemset.nix is up-to-date).

Needs feedback

• [x] Where to put developer documentation (maybe in CONTRIBUTING.md, or perhaps a separate doc -- say, HACKING.md).

[infertux]

@tomeon Thank you for your hard work on this. I have very limited experience with Nix but happy to test this PR whenever you need it.

[tomeon]

@infertux --

I have very limited experience with Nix but happy to test this PR whenever you need it.

Thank you! Sounds like you are the ideal audience for the new INSTALL.md and HACKING.md :slightly_smiling_face: .

Highlighting some other changes: I updated the ci.yml workflow to ignore errors in the nix job that runs nix flake check. This is because that job can fail if the ./Gemfile.nix.lock or gemset.nix become out-of-date with respect to the contents of bashcov.gemspec, and I figured it is likely too onerous to require contributors to keep the Nix-specific assets updated lest their very-probably-not-Nix-specific changes fail CI. To ensure that Nix assets stay up-to-date despite this, I've added a second GitHub Actions workflow that checks whether it is necessary to update Gemfile.nix.lock or gemset.nix, and, if so, opens a PR containing those changes. This workflow uses peter-evans/create-pull-request and runs on a twice-weekly schedule. #80 was created as a test of this process.

[infertux]

@tomeon Just FYI I haven't forgotten you but I've been traveling and don't have access to my workstation to try out this Nix stuff properly. I'm looking at the diff and wondering why do we need to have a separate Gemfile.nix.lock file just for Nix? Why can't we use Gemfile.lock?

[tomeon]

@infertux

[W]hy do we need to have a separate Gemfile.nix.lock file just for Nix? Why can't we use Gemfile.lock?

This is possible, but requires tracking Gemfile.lock with Git. Otherwise nix build and any other Nix commands that trigger building Bashcov would bail out with an error like:

error: getting status of '/nix/store/8rhwb3qc0dsfw9p87s5qwjskzs0r77f2-source/Gemfile.lock': No such file or directory

This is a limitation, or at least a stricture, of Nix flakes.

I figured that the path of least resistance would be to introduce a Nix-specific lockfile, rather than remove Gemfile.lock from .gitignore. Would you prefer to track Gemfile.lock and use it with the Bashcov Nix derivation instead?