7 ms·

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.

LatticeAnimal 3y ago
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
- zamalek 3y ago
  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.
  - lgg 3y ago
    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.
- eviks 3y ago
  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?
- matrss 3y ago
  The store path can be changed with chroot or something similar and the `nix` CLI supports this natively, AFAIK.
pkulak 3y ago
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.
- latexr 3y ago
  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#OPTADDONAPPLICATIONSOFTWAREPACKAGES https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLIC... ² https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
  - maxhille 3y ago
    One of the points of Nix it to _not_ adhere to FHS
    - deleted 3y ago
      [deleted]
    - latexr 3y ago
      See my reply to a sibling comment making the same point: https://news.ycombinator.com/edit?id=39005803 https://news.ycombinator.com/edit?id=39005803
  - matrss 3y ago
    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.
o11c 3y ago
That's more reasonable; if you want it stored elsewhere you can always use a bind mount.

LatticeAnimal 3y ago

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

zamalek 3y ago
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.
- lgg 3y ago
  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.
eviks 3y ago
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?
matrss 3y ago
The store path can be changed with chroot or something similar and the `nix` CLI supports this natively, AFAIK.

pkulak 3y ago

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.

latexr 3y ago
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#OPTADDONAPPLICATIONSOFTWAREPACKAGES https://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLIC... ² https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
- maxhille 3y ago
  One of the points of Nix it to _not_ adhere to FHS
  - deleted 3y ago
    [deleted]
  - latexr 3y ago
    See my reply to a sibling comment making the same point: https://news.ycombinator.com/edit?id=39005803 https://news.ycombinator.com/edit?id=39005803
- matrss 3y ago
  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.

o11c 3y ago

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