| 22 Oct 2025 |
 emily | there's no reason to make that the primary hierarchical axis of organization | 01:31:25 |
 Randy Eckenrode | Yeah, but the Linux kernel, headers, etc probably ought to be in a Linux scope. | 01:31:31 |
| emily | (cf. the mess that is the pkgs/ organization) | 01:31:36 |
| emily | the Linux kernels are scoped into linuxPackages etc. | 01:31:43 |
| emily | as well as packages that vary per-kernel | 01:31:46 |
| emily | but stuff like the Xcodes and openwith – really no reason for them to be under darwin.* | 01:32:24 |
| Randy Eckenrode | I also really want to make darwin.binutils almost an alias for llvmPackages.bintools. | 01:32:29 |
| Randy Eckenrode | Or trash (except there’s an XDG-compliant trash package already). | 01:32:49 |
| emily | yeah, trash probably just needs a disambiguating name | 01:33:14 |
| emily | which is a preexisting problem :) | 01:33:18 |
| Randy Eckenrode | If I wanted to add a Swift package set, what would be the way to go about it to get ahead of the by-name stuff? | 01:33:47 |
 Katalin 🔪 | package sets aren’t affected by by-name | 01:34:13 |
| Katalin 🔪 | only top-level packages | 01:34:29 |
| emily | I would just use the makeScopeWithSplicing stuff and ensure that everything is a callPackage with no arguments I suppose | 01:34:41 |
| emily | scroll up :) | 01:34:45 |
| emily | ^ | 01:34:53 |
| emily | (nothing concrete though, it is in the design phase, but a lot of effort has been spent on it) | 01:35:59 |
| emily | ("everything in by-name without compromises" is a 26.05 goal for me) | 01:36:20 |
| Randy Eckenrode | This is what my branch had before I ran out of time to work on it: https://github.com/reckenrode/nixpkgs/blob/aff41926b0a296636319aca01255118a94132d7f/pkgs/development/compilers/swift/default.nix. | 01:36:23 |
| Randy Eckenrode | With Swift 6.2 supporting a C++ bootstrap, I’m going to be simplifying it and getting rid of versions.json. | 01:36:35 |
| Randy Eckenrode | I would really like to see LLVM get a proper scope, so that overrides work. | 01:37:27 |
| emily | Lun has a PR fixing the rebuild issues with that | 01:38:13 |
| emily | not sure if there are any blockers; cc Lun? | 01:38:24 |
| emily | I remember some issue but i forget what | 01:38:28 |
| Randy Eckenrode | Yeah. It sort of stalled? | 01:38:29 |
| emily | LLVM has been a fun case to think about for by-name, since it is both a fairly complicated splicing-requiring scope and multi-version | 01:39:05 |
| Katalin 🔪 | In reply to @emilazy:matrix.org
^ oh! neat! | 01:40:56 |
| Randy Eckenrode | The direction I would like to go is swiftPackages.swiftc is the compiler. swiftPackages.swift is swiftc plus swift-driver and so on. | 01:42:05 |
| Randy Eckenrode | That way swiftPackages.swift-driver is the same thing that the compiler has. | 01:42:15 |
