3 ms·

> Nix may be the one system package manager that is the exception to this rule Some peers of mine recently experimented with building a Nix buildpack and concl

> Nix may be the one system package manager that is the exception to this rule Some peers of mine recently experimented with building a Nix buildpack and concluded that it won't work. Nix has hardcoded paths for its core directories, and won't work in a security-constrained container.

halostatue 10y ago
Sad face. Nix is the one package manager that looked portable enough and interesting enough to push as a “single” manager for pretty much any system.
- groovy2shoes 10y ago
  Have you had a look at pkgsrc? I know it's not as interesting as Nix or Guix, but I've had very good luck using it on OSX and various Linux distros, as well as its natural habitat of NetBSD. http://pkgsrc.org/ http://pkgsrc.org/
trishume 10y ago
I have no idea where you got that idea. Nix has built in support for building normal non-privileged Docker containers. The paths are hard-coded but just like hard-coded /usr/whatever paths in other unix software, that's what the chroot in the container is for. http://lethalman.blogspot.ca/2016/04/cheap-docker-images-with-nix_15.html http://lethalman.blogspot.ca/2016/04/cheap-docker-images-wit...
- jacques_chester 10y ago
  The paths that are hard-coded are non-negotiably incompatible with how Cloud Foundry locks down its containers. Other language managers don't hard-code and will allow stuff to run from a local directory.
  - zzzcpan 10y ago
    They (other package managers) have to rely on at least a hardcoded elf interpreter or they don't provide binaries and probably don't even handle external dependencies.
    - jacques_chester 10y ago
      > on at least a hardcoded elf interpreter Some rely on gcc, but again, it can be run from a local directory. Various dynamic libraries can be looked up by setting environment variables or passing parameters. I think Nix is a great idea, but I'm not aware of an argument for hardcoding those root paths which truly holds water. It makes sense of NixOS, sure, but that's because it's an environment with top-to-bottom control. The rest of us have to be good and share our toys.
      - trishume 10y ago
        Okay you should have clarified that in your original comment, it's not that Nix is incompatible with unprivileged containers (it includes built in support!) but only with a specific container system that isn't even the most popular one (Docker AFAIK). As for why those paths have to be hard-coded: they don't it's a config variable you can change. When you change it you give up using other people's binaries so you have to build everything yourself, which is exactly like every other distribution system that relies on hard-coded /usr/whatever paths for binaries. The FHS standard is incompatible with Nix's guarantees and dropping it is where it gets all of its power, so it has to use something different, and it chose to make that path /nix/store/whatever
tboettch 10y ago
Does this not work? https://nixos.org/wiki/How_to_install_nix_in_home_(on_another_distribution) https://nixos.org/wiki/How_to_install_nix_in_home_(on_anothe... I've not personally tried it. From reading that document, it seems inconvenient but possible. My understanding is that the hard-coded paths are needed to ensure compatibility of the binary caches, since store paths are often embedded in other artifacts (e.g. RPATH in binaries, shebang line in scripts). You could always run your own cache using another prefix if that's a problem.

halostatue 10y ago

Sad face. Nix is the one package manager that looked portable enough and interesting enough to push as a “single” manager for pretty much any system.

groovy2shoes 10y ago
Have you had a look at pkgsrc? I know it's not as interesting as Nix or Guix, but I've had very good luck using it on OSX and various Linux distros, as well as its natural habitat of NetBSD. http://pkgsrc.org/ http://pkgsrc.org/

trishume 10y ago

I have no idea where you got that idea. Nix has built in support for building normal non-privileged Docker containers. The paths are hard-coded but just like hard-coded /usr/whatever paths in other unix software, that's what the chroot in the container is for. http://lethalman.blogspot.ca/2016/04/cheap-docker-images-with-nix_15.html http://lethalman.blogspot.ca/2016/04/cheap-docker-images-wit...

jacques_chester 10y ago
The paths that are hard-coded are non-negotiably incompatible with how Cloud Foundry locks down its containers. Other language managers don't hard-code and will allow stuff to run from a local directory.
- zzzcpan 10y ago
  They (other package managers) have to rely on at least a hardcoded elf interpreter or they don't provide binaries and probably don't even handle external dependencies.
  - jacques_chester 10y ago
    > on at least a hardcoded elf interpreter Some rely on gcc, but again, it can be run from a local directory. Various dynamic libraries can be looked up by setting environment variables or passing parameters. I think Nix is a great idea, but I'm not aware of an argument for hardcoding those root paths which truly holds water. It makes sense of NixOS, sure, but that's because it's an environment with top-to-bottom control. The rest of us have to be good and share our toys.
    - trishume 10y ago
      Okay you should have clarified that in your original comment, it's not that Nix is incompatible with unprivileged containers (it includes built in support!) but only with a specific container system that isn't even the most popular one (Docker AFAIK). As for why those paths have to be hard-coded: they don't it's a config variable you can change. When you change it you give up using other people's binaries so you have to build everything yourself, which is exactly like every other distribution system that relies on hard-coded /usr/whatever paths for binaries. The FHS standard is incompatible with Nix's guarantees and dropping it is where it gets all of its power, so it has to use something different, and it chose to make that path /nix/store/whatever

tboettch 10y ago

Does this not work? https://nixos.org/wiki/How_to_install_nix_in_home_(on_another_distribution) https://nixos.org/wiki/How_to_install_nix_in_home_(on_anothe... I've not personally tried it. From reading that document, it seems inconvenient but possible. My understanding is that the hard-coded paths are needed to ensure compatibility of the binary caches, since store paths are often embedded in other artifacts (e.g. RPATH in binaries, shebang line in scripts). You could always run your own cache using another prefix if that's a problem.