7 ms·

Brew never had this problem because they chose a sane path without corrupting the system directory. It’s a bad design on part of NixOS and one can even say the

Brew never had this problem because they chose a sane path without corrupting the system directory. It’s a bad design on part of NixOS and one can even say the changes in the macOS were designed to encourage good/sane design.

tomp 6y ago
Exactly. What's more, if we're talking about user hostility, how hostile is when a software doesn't provide a configurable install dir? It's literally a single damn variable!!
- roguas 6y ago
  This is not the case. The problem is that caching is based on the default path which is /nix. So they would have to rebuild all caches.
  - packetlost 6y ago
    Maybe they shouldn't have built it that way then. In my experience nix is nothing but a huge pain in the ass if you don't buy fully into the system, weird design decisions and all
- soraminazuki 6y ago
  > doesn't provide a configurable install dir This is completely false. You can change the installation directory at the cost of losing binary packages. When you change it, packages would be built from source instead. This is what Homebrew does too. What's more, I don't think many package managers provide this option. Not apt, not yum.
  - saagarjha 6y ago
    Homebrew itself recommends you not do this, and while it is getting better at working in this case you will still run into issues if you try to do certain things.
  - hartzell 6y ago
    [Spack](https://spack.io https://spack.io) uses patchelf and additional tooling to relocate it's binary packages to other paths. It generally works, although one has to special case things that burn their install directory into their builds (e.g. Perl).
  - deleted 6y ago
    [deleted]
- rcxdude 6y ago
  it's a single variable which many parts of the system need to have knowledge about, some parts which have basically no way to feed in a variable. You can change the root directory in nix, but that invalidates all binary packages, in part because rpath is not at all configurable.
soraminazuki 6y ago
Writing file to /nix shouldn't corrupt the system directory either. What exactly do you mean by "bad design"?
pmahoney 6y ago
Nix living at a predefined path is integral to how it works. An executable does not dynamically link to a generic "ncurses" but (via rpath) links to a specific compiled version of ncurses (such as /nix/store/81rb87agmp9cbsvg2xm2n4kp9c6309lv-ncurses-6.2). This is the root of all the benefits of Nix such as being able to install things side-by-side that use different versions of things or upgrade and rollback without problems. That predefined path being the same (/nix) across all users of nixpkgs is required to be able to share binary packages (you could perhaps build everything from source, but that's a lot of time, more time even than something like gentoo because package updates require all dependencies to be rebuilt as well). You can call it an insane choice or bad design, but there aren't a whole lot of options here. Could Nix move to a different path? Maybe, but is there a path that all operating systems could abide? If the new path stops working in some future OS, will it still be insane and bad design? Again, maybe, but I happen to love Nix and I use is on macos because it makes my life easier (and I'm on macos for work reasons). I'm willing to bend and do a lot of legwork to be able use Nix, and I'm upset with the Catalina situation. Can follow some discussion here https://github.com/NixOS/nix/issues/2925 https://github.com/NixOS/nix/issues/2925
- bad_user 6y ago
  Unix OS variants have pretty standard paths like /opt or /usr. Going with /nix was basically the best way to run into trouble.
  - deleted 6y ago
    [deleted]
- rcxdude 6y ago
  It's not really a desirable feature, but a limitation of the tools it has to work with, where e.g. specifying an rpath of $NIXROOT/store is not possible.
  - pmahoney 6y ago
    That's an interesting point. But it's not just rpaths, there are many references to things within the nix store. I suspect it would quite difficult to make them bound at runtime or something, but would be nice if possible.
pulisse 6y ago
> Brew never had this problem because they chose a sane path How so? Taking over /usr/local as Homebrew does is guaranteed to cause conflict. Using a dedicated file hierarchy as Nix does is quite reasonable and there's nothing magical about rooting it at /.
- ryanianian 6y ago
  How does it "take over" /usr/local? You can still `./configure --prefix=/usr/local` on your own software and things continue to work as long as you're not installing the same thing that brew is.
  - masklinn 6y ago
    > How does it "take over" /usr/local? Because it shoves all its shit there without asking. Macports actually did it correctly and IME never had any issue.
  - xyproto 6y ago
    Installing several versions of the same piece of software is central to Nix. While locking all needed versions for a specific application provides stability, I can't believe it doesn't come without a large increase of complexity, especially in connection security upgrades which triggers other libraries to need an update as well.
saagarjha 6y ago
> Brew never had this problem because they chose a sane path without corrupting the system directory. Ha, no. They did the absolute worst thing they could have done and now that they are popular they think they "own" /usr/local. (They used to camp out in /usr, but Apple rightfully put a stop to that real quick when SIP came out.)
- Wowfunhappy 6y ago
  This is why, of the two, I prefer Macports.
  - saagarjha 6y ago
    Happy MacPorts user of just over a year as well, for a variety of reasons I won't get into here but that being one of them.
    - etoulas 6y ago
      Very satisfied MacPorts user since 16 years. I really don’t get why brew is a thing...
      - fastball 6y ago
        Because 10 years ago when I first started installing software from the command line on my mac, a large number of the packages I wanted to install were very outdated on MacPorts, and {CURRENT_VERSION} on homebrew. Also `brew cask` is nice. EDIT: also that Macbook had a 128GB HDD, so space was kinda precious, and MacPorts installing its own version of libs that were already on the system was literally taking up GBs of space.
        kitsunesoba 6y ago
        In addition to outdated ports, several times I had issues with macports mucking with or otherwise interfering with the system-bundled copies of things which was a real headache. Seems like the ideal setup would be something like Homebrew, except it "lives" in the ~/Library/Brews/ folder or something to that effect.
masklinn 6y ago
> Brew never had this problem because they chose a sane path without corrupting the system directory. That's a hilarious assertion. Back in the days brew's takeover of /usr/local caused OSX upgrades to get stuck for hours on end (some folks reported more than 12h).
deleted 6y ago
[deleted]

tomp 6y ago

Exactly. What's more, if we're talking about user hostility, how hostile is when a software doesn't provide a configurable install dir? It's literally a single damn variable!!

roguas 6y ago
This is not the case. The problem is that caching is based on the default path which is /nix. So they would have to rebuild all caches.
- packetlost 6y ago
  Maybe they shouldn't have built it that way then. In my experience nix is nothing but a huge pain in the ass if you don't buy fully into the system, weird design decisions and all
soraminazuki 6y ago
> doesn't provide a configurable install dir This is completely false. You can change the installation directory at the cost of losing binary packages. When you change it, packages would be built from source instead. This is what Homebrew does too. What's more, I don't think many package managers provide this option. Not apt, not yum.
- saagarjha 6y ago
  Homebrew itself recommends you not do this, and while it is getting better at working in this case you will still run into issues if you try to do certain things.
- hartzell 6y ago
  [Spack](https://spack.io https://spack.io) uses patchelf and additional tooling to relocate it's binary packages to other paths. It generally works, although one has to special case things that burn their install directory into their builds (e.g. Perl).
- deleted 6y ago
  [deleted]
rcxdude 6y ago
it's a single variable which many parts of the system need to have knowledge about, some parts which have basically no way to feed in a variable. You can change the root directory in nix, but that invalidates all binary packages, in part because rpath is not at all configurable.

soraminazuki 6y ago

Writing file to /nix shouldn't corrupt the system directory either. What exactly do you mean by "bad design"?

pmahoney 6y ago

Nix living at a predefined path is integral to how it works. An executable does not dynamically link to a generic "ncurses" but (via rpath) links to a specific compiled version of ncurses (such as /nix/store/81rb87agmp9cbsvg2xm2n4kp9c6309lv-ncurses-6.2). This is the root of all the benefits of Nix such as being able to install things side-by-side that use different versions of things or upgrade and rollback without problems. That predefined path being the same (/nix) across all users of nixpkgs is required to be able to share binary packages (you could perhaps build everything from source, but that's a lot of time, more time even than something like gentoo because package updates require all dependencies to be rebuilt as well). You can call it an insane choice or bad design, but there aren't a whole lot of options here. Could Nix move to a different path? Maybe, but is there a path that all operating systems could abide? If the new path stops working in some future OS, will it still be insane and bad design? Again, maybe, but I happen to love Nix and I use is on macos because it makes my life easier (and I'm on macos for work reasons). I'm willing to bend and do a lot of legwork to be able use Nix, and I'm upset with the Catalina situation. Can follow some discussion here https://github.com/NixOS/nix/issues/2925 https://github.com/NixOS/nix/issues/2925

bad_user 6y ago
Unix OS variants have pretty standard paths like /opt or /usr. Going with /nix was basically the best way to run into trouble.
- deleted 6y ago
  [deleted]
rcxdude 6y ago
It's not really a desirable feature, but a limitation of the tools it has to work with, where e.g. specifying an rpath of $NIXROOT/store is not possible.
- pmahoney 6y ago
  That's an interesting point. But it's not just rpaths, there are many references to things within the nix store. I suspect it would quite difficult to make them bound at runtime or something, but would be nice if possible.

pulisse 6y ago

> Brew never had this problem because they chose a sane path How so? Taking over /usr/local as Homebrew does is guaranteed to cause conflict. Using a dedicated file hierarchy as Nix does is quite reasonable and there's nothing magical about rooting it at /.

ryanianian 6y ago
How does it "take over" /usr/local? You can still `./configure --prefix=/usr/local` on your own software and things continue to work as long as you're not installing the same thing that brew is.
- masklinn 6y ago
  > How does it "take over" /usr/local? Because it shoves all its shit there without asking. Macports actually did it correctly and IME never had any issue.
- xyproto 6y ago
  Installing several versions of the same piece of software is central to Nix. While locking all needed versions for a specific application provides stability, I can't believe it doesn't come without a large increase of complexity, especially in connection security upgrades which triggers other libraries to need an update as well.

saagarjha 6y ago

> Brew never had this problem because they chose a sane path without corrupting the system directory. Ha, no. They did the absolute worst thing they could have done and now that they are popular they think they "own" /usr/local. (They used to camp out in /usr, but Apple rightfully put a stop to that real quick when SIP came out.)

Wowfunhappy 6y ago
This is why, of the two, I prefer Macports.
- saagarjha 6y ago
  Happy MacPorts user of just over a year as well, for a variety of reasons I won't get into here but that being one of them.
  - etoulas 6y ago
    Very satisfied MacPorts user since 16 years. I really don’t get why brew is a thing...
    - fastball 6y ago
      Because 10 years ago when I first started installing software from the command line on my mac, a large number of the packages I wanted to install were very outdated on MacPorts, and {CURRENT_VERSION} on homebrew. Also `brew cask` is nice. EDIT: also that Macbook had a 128GB HDD, so space was kinda precious, and MacPorts installing its own version of libs that were already on the system was literally taking up GBs of space.
      - kitsunesoba 6y ago
        In addition to outdated ports, several times I had issues with macports mucking with or otherwise interfering with the system-bundled copies of things which was a real headache. Seems like the ideal setup would be something like Homebrew, except it "lives" in the ~/Library/Brews/ folder or something to that effect.

masklinn 6y ago

> Brew never had this problem because they chose a sane path without corrupting the system directory. That's a hilarious assertion. Back in the days brew's takeover of /usr/local caused OSX upgrades to get stuck for hours on end (some folks reported more than 12h).

deleted 6y ago

[deleted]