11–20 of 204 posts
I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the r…
Earlier quoted context omitted.
It's because Nix wants to install into /nix. Once upon a time doing "sudo mkdir /nix" wasn't a problem, but recent macOS releases have made that very hard. Nix could switch to an alternate location on macOS (e.g. /opt/nix) but that has a lot of downsides for interoperability with other systems.
Yikes, I had no idea. What a tough pill to swallow all because the directory nix runs out of is hardcoded.
I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the r…
> I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it.
Since you'd already installed it, wouldn't trying it in some capacity before uninstalling it have made sense?
> What is the reason for all this machinery
Enforcing reproducibility basically.
I don't know all but...
The daemon and APFS volume otherwise readonly /nix that only the daemon can write to can't be created.
The group is probably for the daemon to be able to write to /nix.
The path /nix is important because the remote binary cache paths will miss otherwise and you'll compile everything from source.
> I went with the recommended multi-user install, should I have just used the single user mode instead?
I'm guessing it would work in the way you want, but I always opt for the daemon.
Earlier quoted context omitted.
It's because Nix wants to install into /nix. Once upon a time doing "sudo mkdir /nix" wasn't a problem, but recent macOS releases have made that very hard. Nix could switch to an alternate location on macOS (e.g. /opt/nix) but that has a lot of downsides for interoperability with other systems.
Yikes, I had no idea. What a tough pill to swallow all because the directory nix runs out of is hardcoded.
Using /nix and a separate group and daemon means the store can be read-only and be protected from modification in several ways. This is pretty helpful, as a lot of tools try very hard to write "next to" where they are installed -- corrupting the Nix store.
I sort of wonder if it would be more palatable if the Nix installer was a bit less in your face about what's going on? This would be similar to how Docker's works.
1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev
2. Editor tooling to help guide the writing of expressions (just as anyone learning C# or Rust can use LSP); a better type system for Nix would help here
3. Better documentation for practical things like "Using Nix to manage the dependencies and package a C++ program using Meson", rather than having people piece this together from a bunch of disparate docs
4. A much better CLI UX than `nix-env -qa` and the like (this is ongoing and experimental, but even that broke recently, causing lots of confusion; now it requires `nix --extra-experimental-features nix-command --extra-experimental-features flakes search nixpkgs`)
5. To seriously answer the question: is the Nix language required for the Nix packaging system to exist? Laziness is required, to some degree, but can the next iteration provide an on-ramp which doesn't involve learning a new lang and paradigm? Guix folks sure think so.
I feel like Nix folks have been focused so long on solving the tough problems of declarative, deterministic packaging that they haven't been able to focus on the UX. I also feel like folks for whom Haskell is comfortable may not realize just how absurd it feels to everyone else. Perhaps like the early days of Git.
I do really hope Nix succeeds in this, though; I've been using it, or it's been using me, for several years. [1] and [2] for more info.
The "external dependencies" thing shows how Nix can be a tough sell to those who don't click with it.
I'd say that the other solutions are:
- a README which has a bunch of "apt-get install" commands you can copy-paste from,
- a "setup.sh" script that installs things,
- a container or VM image with the toolchain setup,
- or a tool like asdf.
IMO, Nix is a much nicer solution than these other options, and has the benefits, avoids the downsides of these (but an entirely different set of downsides).
Earlier quoted context omitted.
> What is the reason for all this machinery? Nix wants to use /nix, but Apple wants macOS to be locked down and secure. The compromise was putting /nix on a separate volume. > I discovered it creates a new Unix group, ... installs a daemon This is at about the same level as Docker, fwiw.
> The compromise was putting /nix on a separate directory. Why does a separate directory need a whole other volume? These are just files, right? Why do they need to be on a separate volume?
1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me. 2. What is the right approach?
This is not to bash Nixpkgs, because I installed NixOS and it took me 10min to install a whole OS with Sway, Neovim and some other tools. I guess I'm doing something wrong. But, on MacOS, nixpkgs was not a pleasant experience at all.
With Eelco as a cofounder of DetSys, I feel really excited about where we're going here. I think the world is in many ways primed and ready for Nix, as long as we can help Nix "meet them in the middle." We're working on making Nix more accessible and producing good and usable, production-ready workflows so teams can just pick it up and go. I'd love to hear what y'all think, to help make sure we're going in the right…
I am working on a very large project where multiple solutions have been invented to solve problem which are all handled by Nix:
- Bake in the repository the clone of the dependencies.
- Compile the tool chain to create reproducible builds.
- Create "artifact" builds, to avoid large recompilation times for many developers.
- Use various tools to cache and distribute builds.
- Use a bleeding-edge version of some dependencies.
- Use Node, Java (Android), C++, Rust, …
If only Nix were to run natively on Windows, this would check all the boxes.
Earlier quoted context omitted.
> The compromise was putting /nix on a separate directory. Why does a separate directory need a whole other volume? These are just files, right? Why do they need to be on a separate volume?
OSX requires mounting root folders like /nix with synthetic.conf IIRC.