6 ms·

Cool project, good luck with it! If I may surface one use case: Several years ago I had to manage a bunch of Macs for CI jobs. The build process (Unreal's UAT)

Cool project, good luck with it! If I may surface one use case: Several years ago I had to manage a bunch of Macs for CI jobs. The build process (Unreal's UAT) didn't support running more than one build process at a time, and Docker was really slow, so I'd hoped to use different user accounts to bypass that and get some parallelization gains. Homebrew made that very difficult with its penchant for system-wide installs. So a feature request: I'd love to see a competitive package manager that limits itself to operating somewhere (overridable) in the user's home directory.

alexykn 1y ago
Initial idea for this really came from my dayjob too, we have macs but no way to centrally manage them. The client / server part for the declarative system manager I want to build on top of this is quite far out yet though. At least several months
amarshall 1y ago
Nix effectively has per-user packages, but it’s hard to read into your full use case from your comment.
watermelon0 1y ago
IIRC the main reason here is that brew path is hardcoded during the build process of packages, which means that you wouldn't be able to use bottles. I didn't check, but there is a chance that path is also hardcoded in (some) formulae, so even building from the source might not help here.
- scribu 1y ago
  You could run the build process with chroot or inside Docker, so that the hardcoded paths actually resolve to a designated subdirectory.
  - mananaysiempre 1y ago
    Incidentally, that’s what is usually done in Nixpkgs in similar situations when there’s no better alternative, see buildFHSEnv et al.
  - akdev1l 1y ago
    In many cases the build output also has hardcoded paths unfortunately so doing `brew install` inside a container with the proper volumes it’s not sufficient to fix the issue. Everything would have to run from within the container as well.
deleted 1y ago
[deleted]
benwaffle 1y ago
oh, I guess this is why the nix installer creates 32 macOS users called _nixbld$N
- homebrewer 1y ago
  It's explained in the documentation. https://nix.dev/manual/nix/2.25/installation/multi-user https://nix.dev/manual/nix/2.25/installation/multi-user

alexykn 1y ago

Initial idea for this really came from my dayjob too, we have macs but no way to centrally manage them. The client / server part for the declarative system manager I want to build on top of this is quite far out yet though. At least several months

amarshall 1y ago

Nix effectively has per-user packages, but it’s hard to read into your full use case from your comment.

watermelon0 1y ago

IIRC the main reason here is that brew path is hardcoded during the build process of packages, which means that you wouldn't be able to use bottles. I didn't check, but there is a chance that path is also hardcoded in (some) formulae, so even building from the source might not help here.

scribu 1y ago
You could run the build process with chroot or inside Docker, so that the hardcoded paths actually resolve to a designated subdirectory.
- mananaysiempre 1y ago
  Incidentally, that’s what is usually done in Nixpkgs in similar situations when there’s no better alternative, see buildFHSEnv et al.
- akdev1l 1y ago
  In many cases the build output also has hardcoded paths unfortunately so doing `brew install` inside a container with the proper volumes it’s not sufficient to fix the issue. Everything would have to run from within the container as well.

deleted 1y ago

[deleted]

benwaffle 1y ago

oh, I guess this is why the nix installer creates 32 macOS users called _nixbld$N

homebrewer 1y ago
It's explained in the documentation. https://nix.dev/manual/nix/2.25/installation/multi-user https://nix.dev/manual/nix/2.25/installation/multi-user