Homebrew recipe for nix

[alper]

Is your feature request related to a problem? Please describe.

I find the installation and uninstallation instructions for nix on macOS to be intimidating and complicated. I'd like to try nix but I don't see myself going through the steps listed on the website for a benefit which to me at the moment is still uncertain.

Describe the solution you'd like

Looking through the issues here it seems a lot of people are running homebrew already for their dev dependencies. If homebrew is part of the system, then might it not make sense to also provide nix as part of homebrew?

So: Can we have nix on macOS as a homebrew recipe for ease of installation and uninstallation?

Describe alternatives you've considered

No real alternatives. I use homebrew for all my developer tools already and will refuse to use tools if they are not provided through homebrew.

[abathur]

I checked with a community member who's fairly familiar with Homebrew about this. I'll try to ~summarize:

• more of a Homebrew issue; upstreams aren't responsible
• Homebrew packages, as far as they know, can only install into a prefix
• things Nix needs to do on macOS (partitioning, creating users) may be a real challenge

They mentioned a "classic" approach where you'd install the formula but still have to run a script to complete the install (if I understood right, the formula would just be installing the installer--sounds like this wouldn't really satisfy your concern).

This would be nice, but I hesitate to encourage anyone to invest a lot of time in it unless someone familiar with both Nix and Homebrew is attesting to the feasibility.

(To be clear, I'm not really a decider here--just someone who asked around and reported back.)

[edolstra]

That sounds right. Installation via Homebrew wouldn't really simplify anything: whatever the Nix installer currently does, the Homebrew recipe would have to do as well.

Also, Nix is largely an alternative to Homebrew on macOS, so installing via Homebrew just sounds like it adds unnecessary complexity.

[alper]

Thanks @abathur for checking this. I think that's all I can ask for at this moment.

@edolstra I know it's an 'alternative' but for me at this point it's not really an alternative yet. This would make the adoption path more smooth. Also I'd question all of the really funky stuff that Nix plans to do to my macOS system which I would reject always. That's been a similar reason why before homebrew I for instance never used things like macports either.

[alper]

Also, Nix is largely an alternative to Homebrew on macOS

I'm reading the manual and trying to figure this out.

Nix does pretty much the same thing as Homebrew as you say above. But why does brew manage to do this without messing up my entire system? (It doesn't even create a user.) What's the justification for nix to do all kinds of magic, creating root folders etc. etc. I'm reading the manual and I don't see anything that would justify this.

[SuperSandro2000]

The build sandbox requires the nixbld users so that you can build in parallel in isolation. The nix store path is hardcoded to one location because it gets hardcoded inside of the packages. Also it requires special mounting to be read only for the normal users.

[abathur]

Nix does pretty much the same thing as Homebrew as you say above. But why does brew manage to do this without messing up my entire system? (It doesn't even create a user.) What's the justification for nix to do all kinds of magic, creating root folders etc. etc. I'm reading the manual and I don't see anything that would justify this.

AIUI you're looking for multiple ~contextual justifications...

• Default installs use /nix/store as the store path.
  • Anyone can technically change this, but it means living without the free public binary cache (you'll be on your own wrt to building everything unless your org stands up its own infra).
  • Apple made the root read-only in macos catalina and only gave us fixes that entail writing root-owned file (/etc/synthetic.conf) to set up an empty mount point and a volume.
    • Changing the store path is technically a fix, but it would either require disrupting the entire nix community to migrate, or someone to sponsor standing up a parallel set of build/cache infra just for macos.
    • If users use filevault, the built-in automounter won't mount the volume in time to keep any restored apps/files on the nix store volume from crashing, so we also need a launchdaemon to ensure it mounts early enough.
    • Before this macos change, you could also use the simpler single-user install. But all of the complications necessary to accommodate the read-only root undermine the entire point of simple single-user installs, so the option was disabled.
• a single-user install is similar to a homebrew install aside from the /nix/store issue, and a multi-user install uses a daemon and a number of build users. More detail in https://nixos.org/manual/nix/stable/installation/nix-security.html (and subsections).

[alper]

The build sandbox requires the nixbld users so that you can build in parallel in isolation. The nix store path is hardcoded to one location because it gets hardcoded inside of the packages. Also it requires special mounting to be read only for the normal users.

I don't see this in the documentation. The documentation only implies that it will do a certain amount of violence to my system that will be arbitrarily difficult to undo.

(Same reason I never used stuff like Macports.)

[alper]

a single-user install is similar to a homebrew install aside from the /nix/store issue

Yeah, it turns out single-user is no longer supported for macOS. Sounds like it would be ideal.

Changing the store path is technically a fix, but it would either require disrupting the entire nix community to migrate

I think it's a bit weird to hardcode in a root folder if /usr/local/ and /opt/ are right there.

[abathur]

Yeah, it turns out single-user is no longer supported for macOS. Sounds like it would be ideal.

As I said:

• Before this macos change, you could also use the simpler single-user install. But all of the complications necessary to accommodate the read-only root undermine the entire point of simple single-user installs, so the option was disabled.

I think it's a bit weird to hardcode in a root folder if /usr/local/ and /opt/ are right there.

Do you think calling it weird will change it? This was relitigated repeatedly in #2925 (which you participated in).

And again:

• Anyone can technically change this, but it means living without the free public binary cache (you'll be on your own wrt to building everything unless your org stands up its own infra).

[alper]

Do you think calling it weird will change it? This was relitigated repeatedly in #2925 (which you participated in).

(Funny, totally forgot about that.)

What else would change it? I'm just saying that this way, Nix for me is the same as Macports/Darwin was, a non-starter until Homebrew appeared.

Usually my reaction on these things is relatively correct and I'm sure that this is holding up a lot of adoption of Nix on macOS (which is a shame).

[abathur]

As 2925 illustrates, this isn't a unique perspective. There are plenty of people (myself included) who'd prefer not having to swim against the flow, here. But (for the reasons I listed among others) it isn't trivial to change a ~20-year-old default that is (for now) fundamental to the public caches that make nix/nixpkgs practical for everyday users.

I don't have the high-level perspective to know (perhaps someone else will weigh in), but my ~guess is that it's down one of two paths:

• An organization decides they value simplifying the macOS installs enough to pony up the manpower and money to do whatever it takes to change the path on macOS. Guessing, but probably: create an RFC that's ultimately accepted, change and test the installer, figure out how to migrate or avoid messing up existing installs, sponsor and maintain new infra, fix any blocking issues in nix/nixpkgs, and (if they're saints) help with the extra support load from people with a script/image/integration broken by this or who get confused by the difference between their system and some old blog post or gist.

• Wait for (or... help?) the intensional store effort come to fruition. More in:

  • [RFC 0017] Intensional Store
  • [RFC 0062] Content-addressed paths
  • Content-addressed Nix − call for testers

[alper]

Thanks, I'll read up on that at some point though for my current knowledge level it seems a bit over my head.

I found another person saying the same thing: https://ianthehenry.com/posts/how-to-learn-nix/flakes/

I understand that it is possible to hack the install script to do a single-user install on macOS, but it was already pretty difficult to install in the first place, and this makes it basically impossible to market Nix to macOS users who are not already “sold” on Nix.

[mtreca]

Piggybacking on this issue since I was looking for the opposite and Google led me here.

Nix-darwin provides a way to install packages and casks through homebrew, but does not provide a recipe to install homebrew itself. Do you think it would be doable? I can open a new issue related to this if needed.