| 22 Oct 2025 |
 emily | but the reason to switch to lib.extendMkDerivation is that it makes .overrideAttrs etc. actually work properly | 01:19:54 |
| emily | and avoids the results having a somewhat dodgy .override (albeit one that is clobbered by callPackage in practice) | 01:20:21 |
 Randy Eckenrode | The magic filename stuff is largely the point of the Meson stuff. It’s to reduce the boilerplate of copying in the files and setting the version/etc. With Swift Build, we don’t need that stuff at all. You could just use swiftBuildHook (or whatever it gets called) and the internal SDK. | 01:20:31 |
| Randy Eckenrode | Inheriting meta seems worse. You would end up with every derivation copying and pasting meta = { description = "blah"; inherit (standardMeta) etc etc etc; }. | 01:21:36 |
| emily | it could be done with (magicMesonHook ./.) or similar though | 01:22:39 |
| Randy Eckenrode | True. | 01:23:03 |
| Randy Eckenrode | Would that make Darwin’s having the only two hooks that take arguments? | 01:23:20 |
| emily | I've been working on proper support for scopes etc. for by-name | 01:23:25 |
| emily | so the magic filename stuff probably can't last forever anyway :) | 01:23:35 |
| emily | though ideally we just get Swift Build working and don't have to maintain our own build systems for it all any more | 01:23:55 |
 debtquity | seems some applications that rely on gtk are breaking on unstable | 01:23:56 |
| Randy Eckenrode | What do you mean by scopes for by-name? Like there would be a pkgs/python/by-name? | 01:23:59 |
| emily | which would also cut down on the boilerplaet a lot | 01:24:08 |
| emily | * which would also cut down on the boilerplate a lot | 01:24:11 |
| Randy Eckenrode | I wish the by-name infrastructure were exposed as a function. | 01:24:27 |
| emily | that's already possible-ish (tclPackages moved to by-name and there's a draft for Python), what isn't possible is scopes that are inside pkgs/by-name itself | 01:24:42 |
| * Randy Eckenrode goes to look at the implementation. | 01:26:52 |
| Randy Eckenrode | It’s importing by-name-overlay.nix. | 01:27:24 |
| emily | that will probably end up abstracted away in the process yeah | 01:27:39 |
| emily | (although in practice it is just going to be the automatic path for scopes rather than something you have to think about) | 01:28:02 |
| Randy Eckenrode | Which is different from lib.packagesFromDirectoryRecursive. | 01:28:06 |
| Randy Eckenrode | I want to move Darwin to the by-name-overlay for 25.11. | 01:28:32 |
| Randy Eckenrode | * I want to move Darwin to the by-name-overlay for 26.05. | 01:29:10 |
| Randy Eckenrode | Switch from lib.packagesFromDirectoryRecursive to the overlay and get rid of the randomly ordered list of callPackage. | 01:29:15 |
| emily | if me and Wolfgang do our jobs then literally everything will be in by-name by 26.05 | 01:29:41 |
| Randy Eckenrode | And kill the stupid gas stuff. I’ve been putting off reworking GNAT to use the normal assembler and add aarch64-darwin support. | 01:29:44 |
| emily | so I wouldn't spend too much time on it :) | 01:29:53 |
| Randy Eckenrode | Darwin would be in pkgs/os-specific/darwin/by-name? | 01:30:08 |
| emily | pkgs/by-name/darwin rather | 01:30:21 |
| emily | * pkgs/by-name/da/darwin rather | 01:30:24 |
