| 26 Jul 2024 |
 infinisil | To test all of them together :P | 00:08:08 |
 Philip Taron (UTC-8) | I’m gun shy on that: I’ve gotten so much “I can’t review this” negative feedback on “treewide” changes | 00:08:15 |
| Philip Taron (UTC-8) | They originated as a single branch! | 00:08:33 |
| infinisil | Haha | 00:08:39 |
| infinisil | I see, no worries ;) | 00:08:51 |
| infinisil | I usually want to err on the side of "merge fast and often", which I guess does work better with smaller PRs, but it's hard to strike the balance | 00:10:06 |
| Philip Taron (UTC-8) | Don't I know it. I also like merge fast and often, but, uh, that relies on fast reviews and merges, which are only some of the time present (for obvious open source reasons!) | 00:11:01 |
| infinisil | Yeah 😅 | 00:11:55 |
| infinisil | Philip Taron (UTC-8): Hmm weird, https://github.com/NixOS/nixpkgs-check-by-name/blob/main/.github/workflows/after-release.yml didn't run | 23:29:38 |
| infinisil | https://github.com/NixOS/nixpkgs-check-by-name/actions/workflows/after-release.yml | 23:29:47 |
| Philip Taron (UTC-8) | I saw that. The release went out, though./ | 23:30:09 |
| Philip Taron (UTC-8) | * I saw that. The release went out, though. | 23:30:11 |
| infinisil | It definitely worked before 🤔 https://github.com/NixOS/nixpkgs/pull/303140 | 23:34:26 |
| infinisil | For others checkin in here, gonna work around it: https://github.com/NixOS/nixpkgs-check-by-name/pull/90 | 23:44:05 |
| infinisil | Philip Taron (UTC-8): Oh no, the Cargo.lock is still at 0.1.1, why did this not break anything 😆 | 23:46:07 |
| Philip Taron (UTC-8) | Must be some consequence of the cargo update changes?? | 23:48:10 |
| infinisil | I noticed it from those: https://github.com/NixOS/nixpkgs-check-by-name/actions/runs/10118954269#summary-27986608230 | 23:48:51 |
| infinisil | But like, I'd expect the build itself to fail from this | 23:49:09 |
| infinisil | Not sure what the consequences of a mismatched Cargo.{toml,lock} are | 23:49:47 |
| infinisil | Philip Taron (UTC-8): I guess I should finish the Changelog PR, because there it would be handled automatically: https://github.com/NixOS/nixpkgs-check-by-name/pull/46/files#diff-d9002f82f23cc9b3c1545ec7d5ddfc3911aec8ba24d4e3d21c73f40355da2a16R85
cargo set-version --manifest-path "$root"/Cargo.toml "$next"
This updates both Cargo.{toml,lock}, without updating anything else :)
| 23:55:42 |
| 27 Jul 2024 |
| infinisil | * Philip Taron (UTC-8): I guess I should finish the Changelog PR, because there it would be handled automatically: https://github.com/NixOS/nixpkgs-check-by-name/pull/46/files#diff-d9002f82f23cc9b3c1545ec7d5ddfc3911aec8ba24d4e3d21c73f40355da2a16R85
cargo set-version --manifest-path "$root"/Cargo.toml "$next"
This updates the version in both Cargo.{toml,lock}, without updating anything else :)
| 00:05:49 |
| 29 Jul 2024 |
|  @imincik:matrix.org left the room. | 10:01:47 |
| 1 Aug 2024 |
|  Sigmanificient joined the room. | 11:40:49 |
| 3 Aug 2024 |
|  Randy Eckenrode joined the room. | 14:24:05 |
| Randy Eckenrode | Let me know if I should move this to #dev:nixos.org, but I have a few questions about by-name.
I’m working on the Darwin SDK refactor. As part of that work, I want to move the SDK and source-releases out of os-specific/darwin to the by-name hierarchy. For the SDKs, this is mostly easy. I have a by-name/ap/apple-sdk folder with a package.nix. The source-releases are another matter (see below).
For the SDK, there will be multiple versions. For how to handle those, I can override apple-sdk in all-packages.nix. The question is, do I have to enumerate each versioned SDK package manually in all-packages.nix, or can I do the following?
inherit (callPackage ../by-name/ap/apple-sdk/all.nix { })
apple-sdk_10_12 apple-sdk_10_13 apple-sdk_10_14 apple-sdk_10_15
apple-sdk_11 apple-sdk_12 apple-sdk_13 apple-sdk_14;
For the source-releases, I need a scope. The SDK overrides packages in the scope to the versions it needs for that SDK version (e.g., the 11.3 SDK uses Csu 85 while the 14.4 SDK uses Csu 88). I know things in by-name need to be derivations, but is it keeping in the spirit to passthru a scope? Essentially, I have apple-oss/Csu, add that to a scope, and passthru the scope on the apple-oss derivation. The SDK can then do apple-oss.overrideScope, and things work as expected.
We’ve been talking about various options in #macos:nixos.org. One possibility is keeping it as a package with the other packages not nested (so by-name/ap/apple-oss-Csu, etc). Another is keeping the scope in os-specific/darwin/apple-oss, add it to all-packages.nix, and ignore the check failure in the PR. Not really sure what the best approach would be or what the plan is to handle scopes in by-name (if there is one).
| 14:24:14 |
 emily | (FWIW my proposal was to do by-name/ap/apple-oss-* but have an apple-oss scope defined outside of by-name that just does { Csu = apple-oss-Csu; … } so that the various packages can still depend on apple-oss and get the scope overrides atomically – not sure if that's what Randy meant by "keeping it as a package with the other packages not nested") | 14:25:59 |
| emily | I do think that it's just wrong for the checker to complain about foo = callPackage ./bar { } if the result of foo is a scope or attrset or something instead of a derivation. (I don't know if it actually does or not, but Randy was worried about it) | 14:26:47 |
| emily | unless the intent is that nobody should ever add a top-level scope ever again | 14:26:56 |
| Randy Eckenrode | I was assuming a by-name/ap/apple-oss that provided a scope, but the packages were packaged separately. I wouldn’t be able to reference a scope defined outside of the SDK. | 14:28:10 |
| Randy Eckenrode | I guess I could define the scope in the SDK. That seems like a lot of boilerplate though. | 14:28:49 |
