Hacker News Reader

Comment by vilunov | Hacker News Reader

That, and also that it has to be installed globally with the absolute path of `/nix/`. Sure, you can change it, but the packages won't work then.

View on HN

That’s been an issue for ever. I can only assume it’s a really hard problem to make the install location configurable. Plus, folks like me who don’t use Mac really don’t care. It’s a perfectly fine place to it.

EDIT: LatticeAnimal answered it. You can’t use the cache with a custom directory.

And it has to be global because the whole point is that there’s only one place and all derivations are shared between user accounts. If everyone had a ~/.nix, hard drives would explode on multi-user systems.

A better place would be /opt/nix, that’s what /opt is for¹. There is a Filesystem Hierarchy Standard² and following it would lead to fewer incompatibilities than ignoring it.

¹ https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLIC...

² https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

NixOS and nix, by design, do not and can not follow FHS, so I guess they decided to shorten that path while at it. That said, it is possible to use a different location than /nix/store through chroot/proot/bubblewrap or similar mechanisms and AFAIK the `nix` CLI can do this natively.

Perhaps one of us is misunderstanding the other, but I don’t mean follow FHS for what it installs, I mean doing it only for its root. /opt is exactly the place where you put the “other”. Homebrew (by default on Apple Silicon) does it perfectly well in a self-contained manner that does not need to fudge with the hierarchy.

I understand what you mean, I just made a guess why it was not a priority to follow FHS for its root when it doesn't really follow FHS anywhere else anyway. Also, /nix is self-contained as well, so that is not an advantage to following FHS.

Moving /nix to another location would require a lot of package authors that make the assumption of /nix/store being a constant to rewrite their packages, an effort that doesn’t really seem worth it.

I don't believe this is a big issue, typically package authors just use $output variable which returns whatever path the package should be stored at.

The real reason for it are libraries. The binaries that are packaged in /nix/store very often depend on at least glibc and many other libraries. Their path is hardcoded to /nix/store/...

Changing the path would require recompiling, which also means all the caches that were generated would have to be purged and everything would need to be rebuilt.

Though in my limited experience I was able to also use a symlink. I got a warning that some thing could break but all things I was interested in continued to work.

One of the points of Nix it to _not_ adhere to FHS

See my reply to a sibling comment making the same point: https://news.ycombinator.com/edit?id=39005803

iirc, you can have a different base path, but you have to recompile every package locally to have the correct patched paths. I forget where I read about this.

Seems like an unavoidable consequence of how modern software is built

It's actually an unavoidable consequence of what makes Nix great. There is no loader that looks up libs in /lib, the paths are directly hardcoded into the binary. This is how Nix sidesteps versioning hell entirely.

It really isn't unavoidable on macOS. @rpath is designed specifically to handle this sort of thing, and is how all the command line tools distributed with Xcode link to libraries embedded in Xcode and continue working even when you drag Xcode to a new location.

Admittedly supporting that would require updating how all the tools are built and not just defaulting to Whatever Linux Does™, which is probably too much effort to justify in this case, but it is hardly an unsolvable (or even an unsolved) problem.

As far as I understand, you could pad the paths for the server farm builds then overwrite them on local machine install like Spack package manager does, so maybe not unavoidable?

The store path can be changed with chroot or something similar and the `nix` CLI supports this natively, AFAIK.

That's more reasonable; if you want it stored elsewhere you can always use a bind mount.

Reply on news.ycombinator.com