Is there a BSD equivalent of Coretools?

1

I use nixos, most of my team is on MacOS. Some of the scripts they write break on my machine because of gnu/bsd differences in, for instance, mktemp.

Since I’m in the minority, I’d like to just place bsd tools in the devShell rather than convince them to use gnu tools. I imagine it would look something like this in my project’s flake.nix:

        devShells.default = pkgs.mkShell {
          packages = [
            pkgs.coreutils-bsd

Except there isn’t actually a coreutils-bsd.

If the answer is “no”. Well shucks. If the answer is “yes”, can I get some pointers on how I could’ve searched for it?

2

I see two options:

  1. Make your scripts POSIX-compatible. That way, any POSIX-compatible coreutils should behave the same.
  2. Convince your mac colleagues to install Nix on their macs and make the scripts run inside a Nix shell with GNU coreutils, toybox, busybox, uutils or whichever coreutils in Nixpkgs you like.
3

Another alternative would be to create an even-more minimal devshell. mkShell inherits from stdenv.mkDerivation, which will bring a lot of GNU utilities. However, you could “roll your own” derivation to avoid bringing in those commands.

You may also want to look at GitHub - numtide/devshell: Per project developer environments

4

I don’t know if we do have them, but I imagine they can be packaged. Maybe search github for Nix expressions that mention whatever their canonical source repositories are?

5

The BSDs typically have all the base OS in a single repo: kernel, libs, userland programs, distribution / release mechanisms, and more.

So, as such, there isn’t a specific “package” that collects a specific subset of programs that matches the content of gnu coreutils as a replacement. That collection was made to lay on top of a base OS (mostly kernel and libs) and provide alternate versions of those tools, partly to have consistency across what was then a much more diverse set of Unix vendor platforms.

Even among just the BSDs, there’s not a common codebase for these; patches flow between them from time to time, but they also have divergence.

You certainly could pick and choose and package the ones that suit you(r coworkers’ code), presumably from the Darwin sources.

Are your coworkers using nix at all, or is that also only you? Because if they are, then there are clearly impure dependencies leaking in from the host system. If they’re on-board with nix concepts, that’s a problem they can hopefully agree needs to be solved, regardless of which tools are brought into the devshell to fix it.

6

Thanks all for the replies. I had assumed “surely somebody has built this” and that I was just looking in the wrong place. I suppose that that was a bad assumption. Perhaps I’ll try to build it.

I’m the only nix user on this project, I’ve been maintaining the flake.nix and switching between MacOS and NixOS as a bit of a learning exercise. The hope was to be able to make it into the easiest way forward and then pitch it to the team. Unfortunately my flake.nix is peppered with workarounds to problems that I’m not savvy enough to fix (1, 2), so until I cultivate that savvyness, I don’t think it’s really clean enough to be convincing.

3 Likes