| 23 Nov 2025 |
 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 |
| niklaskorz | Indeed, all macOS apps have to use the system libc | 12:02:18 |
| niklaskorz | that's also why we can't do fully static binaries on macOS | 12:02:26 |
| bake.monorail | btw, I appreciate your effort, but this thing was much more easy to understand if it was written in bash :D | 12:03:37 |
| bake.monorail | * btw, I appreciate your effort, but this thing would have been much easier to understand if it was written in bash :D | 12:03:49 |
 Randy Eckenrode | So if we can figure out the URL, it might be possible to package it? | 12:04:10 |
| bake.monorail | maybe it's just the fact that I'm a rust noob | 12:04:15 |
| niklaskorz | I'm not writing a mach parser in bash ⚰️ | 12:04:17 |
| bake.monorail | llvm-readobj not enough? | 12:04:39 |
| niklaskorz | well for this particularly usecase otool -L would have done the job | 12:06:01 |
| niklaskorz | but also I wouldn't want to port the recursive copy algorithm in bash | 12:06:14 |
| niklaskorz | generally not being able to read the bash mess that was nix-bundle-macos is the reason I wrote this in Rust in the first place | 12:06:40 |
| niklaskorz | * but also I wouldn't want to port the recursive copy algorithm to bash | 12:06:53 |
