[Question] /run symlink necessary?

[HealsCodes]

I don't pretend I have nearly enough knowledge about the inner workings of nix-darwin but I was wondering if the /run symlink it adds to /etc/synthetic.conf is really necessary or if it wouldn't actually be more in the spirit of targetting darwin / macOS to directly refer to /private/var/run?

I'm mainly asking because the way /run is created also makes it so it can't be hidden from Finder either (sudo chflags -h hidden /run does not work because the symlink is part of the read-only root volume).

[tmillr]

I'm not sure but I could have sworn there used to be a module option to disable (opt-out) the creation of /run. Check all the options, although maybe it got removed?

[HealsCodes]

Unless it's not mentioned in Darwin Configuration Options it seems that one was removed.

[emilazy]

I don’t think we have a specific configuration switch for this. I believe the only obstacle to us using /var/run directly is that a good number of upstream Nixpkgs packages hardcode paths like /run/current-system/sw/bin/...; we would need to assess how much that matters and whether it’d be viable to parameterize them by the host OS. it would probably be a bit cleaner, but it might be a lot of work to sift through and see how much it would matter; if someone did a quick survey of the uses of /run in the non-NixOS parts of Nixpkgs that would help.

It would also be nice if we could hide the synthetic /run directory but I don’t know if there’s any way to achieve that.

[HealsCodes]

I was afraid that 'hard coded /run path' was a reason - sad though given that pretty much most common build systems used by the majority of packages support specifying or auto-detecting the appropriate path for their runtime state (--runstatedir for autoconf for example).

Looking into hiding /run so far was fruitless on my end - synthetic.conf only allows you to create links in the root volume but since it's read-only outside of that process I couldn't find a way to change attributes of the generated link later on.

I still appreciate that this issue isn't just brushed off as 'can't be helped' :)

[emilazy]

In this case the “upstream” is Nixpkgs passing paths like /run/current-system/sw/bin/helper-tool or /run/current-system/share/applications to build systems so that they can find the correct packages at runtime on NixOS – in the context of NixOS that’s exactly the correct thing to do, but it means that we need to have /run to maintain compatibility unless we can get Nixpkgs to use /var/run everywhere on Darwin.

I’d prefer to just use the native paths as long as we can maintain compatibility with upstream packages, or if it turns out that the things it breaks shouldn’t really be relevant on macOS, although there’s an argument that we might break random scripts that expect the NixOS paths and I do want to prioritize having the same interfaces as NixOS when practical.