| 23 Nov 2025 |
 Randy Eckenrode | I rebased it on master to make it suck less if you want to build it.. | 00:57:45 |
| Randy Eckenrode | * | 00:57:50 |
 bake.monorail | Do you know if there's a portable way to distribute software through nix on macOS without root?
I'm thinking something like 1) Linux's user namespaces or 2) or using /tmp/nix/store as /nix/store.
AFAIU 1) is not viable while 2) would mean that any user of the machine can tamper with the software, given that I think /tmp is shared between users.
Ideas? | 10:40:22 |
| bake.monorail | Ah! I can just use /Applications/MyApp.app/nix/store as /nix/store! | 11:32:53 |
 niklaskorz | the metal shader compiler has been moved from Xcode 26 into a separate package but it's still not redistributable, meh | 11:48:31 |
| niklaskorz | I actually made a thing that does that for you | 11:50:05 |
| niklaskorz | https://codeberg.org/niklaskorz/nix-bundle-darwin | 11:50:11 |
| Randy Eckenrode | Is the package still hidden behind a developer account? | 11:51:32 |
| niklaskorz | I might just give that a try with Tiny Glade (I hope it lets me override the Vulkan ICD) | 11:51:36 |
| niklaskorz | even better, you can only download it through Xcode (might be interesting to test if the URL it accesses is actually unauthenticated) | 11:52:05 |
| niklaskorz | xcodebuild -downloadComponent MetalToolchain | 11:52:18 |
| niklaskorz | only the Windows version can be downloaded from the web portal, but that does require a developer account | 11:52:55 |
| bake.monorail | Ah, I thought that was doing something different since it says "Unrestricted app location – nix-bundle-macos requires apps to be in /Applications/". | 11:55:34 |
| niklaskorz | well, it does patch all binaries to use rpath | 11:55:50 |
| bake.monorail | Ah so makes all the binaries "portable"? Like using $ORIGIN on linux, right? | 11:56:42 |
| niklaskorz | yup, but the portability is currently restricted to only supporting dynamic libraries in the nix store | 11:56:56 |
| niklaskorz | there is an issue to extend that to arbitrary nix store files | 11:57:06 |
| niklaskorz | https://codeberg.org/niklaskorz/nix-bundle-darwin/issues/1 | 11:57:13 |
| bake.monorail | I'd avoid run-time hacks tbh | 11:57:28 |
| niklaskorz | I'd make it opt in | 11:57:41 |
| niklaskorz | but also it's seldom needed on macOS | 11:57:46 |
| bake.monorail | I'm thinking having a nix store in /Applications/MyApp.app is rather acceptable. | 11:57:47 |
| niklaskorz | apps are supposed to access app-bundle files using the OS APIs | 11:57:59 |
| niklaskorz | not by directly accessing file paths | 11:58:04 |
| bake.monorail | The downside is that the user needs to copy it there, which AFAIU is typical anyway. | 11:58:06 |
| niklaskorz | so having a hardcoded nix store path that is not a dynamic library in a macOS app is pretty rare anyway, even for apps in nixpkgs | 11:58:49 |
| bake.monorail | What do you mean? If you, say, generate a script it's rather easy to have path hardcoded. | 11:59:42 |
| bake.monorail | * What do you mean? If you, say, generate a script it's rather easy to have paths hardcoded. | 11:59:48 |
| niklaskorz | for wrapper scripts? that's a special case I definitely want to handle soon-ish | 12:00:13 |
| bake.monorail | So, you do the rpath thing, which is kinda nice. I was thinking it should be the default on Linux as well, but the problem is that you can't use $ORIGIN for the loader (i.e., PT_INTERP). I guess on mac you don't have the same problem since you don't distribute the libc. Correct? | 12:01:52 |
