| 23 Nov 2024 |
 Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
up to you :) the two things that make sense are to do it all in one PR or to land the setup hook PR with known regressions and then fix them one by one I think I fixed all of the regressions already with the setup hook (ran nixpkgs-review overnight one day, then looked through the failures and fixed them) | 01:20:49 |
 emily | ah | 01:21:16 |
| emily | wait, but then what was that about PRing into a branch? | 01:21:22 |
| Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
wait, but then what was that about PRing into a branch? I originally targeted master with the setup hook PR before I saw how many packages it rebuilt (after said overnight build) | 01:23:01 |
| Tomodachi94 (they/them) | I'm a bit confused about what you're asking | 01:23:10 |
| Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
up to you :) the two things that make sense are to do it all in one PR or to land the setup hook PR with known regressions and then fix them one by one I don't anticipate many regressions with the other three big changes I have planned (splitting ant-contrib, removing our custom wrapper, building from source) | 01:23:32 |
| emily | ah, sorry | 01:23:41 |
| emily | I didn't realize the setup hook and the -contrib thing were separate | 01:23:47 |
| emily | I'm a bit unclear on "Should I draftify the setup hook PR and reuse it for all of the refactors, then undraft it once it's done?" then | 01:24:01 |
| Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
I'm a bit unclear on "Should I draftify the setup hook PR and reuse it for all of the refactors, then undraft it once it's done?" then Basically turning the setup hook PR into a draft and repurposing it for all of the refactors | 01:24:27 |
| Tomodachi94 (they/them) | Probably retitling it ant: refactor. Or would a new PR be better to avoid creating a hellthread until the very end when it's undrafted? | 01:25:21 |
| emily | it seems best just to merge it as-is and then build on top of it? | 01:25:37 |
| Tomodachi94 (they/them) | I agree :) | 01:25:53 |
| Tomodachi94 (they/them) | * I don't anticipate many regressions with the other three big changes I have planned (splitting ant-contrib, removing our custom wrapper, which leads into building from source) | 01:32:56 |
| Tomodachi94 (they/them) | * I don't anticipate many regressions with the other three big changes I have planned (splitting ant-contrib and removing our custom wrapper, which leads into building from source) | 01:33:11 |
| Tomodachi94 (they/them) | Yay release notes merge conflicts /s | 01:44:20 |
| Tomodachi94 (they/them) | re. @Toma's comment on the PR: I think I have caught all of the regressions, does that ease your mind at all about including the hook in the core ant package? | 01:46:15 |
| emily | I recommend antHook or ant.hook, there is some desire to move away from implicit hooks in general | 01:47:34 |
| emily | e.g. from cmake to cmakeHook or such | 01:47:39 |
| emily | beginners generally find it confusing that adding a dependency restructures how their entire build works, and separate hooks give us natural configuration points to do things like e.g. propagating Ninja for faster CMake builds without polluting the CMake package itself | 01:48:22 |
| emily | (haven't seen the comment, maybe what I'm saying is irrelevant) | 01:48:31 |
| Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
(haven't seen the comment, maybe what I'm saying is irrelevant) Completely relevant, Toma mentioned that the alphabet causes regressions because of the implicit hook (the big one was that ant comes before cmake) | 01:49:49 |
| Tomodachi94 (they/them) | (Aside: The Alphabet of Nixpkgs) | 01:50:03 |
| Tomodachi94 (they/them) | * (Aside: The Alphabet of Nixpkgs song when /lh) | 01:50:14 |
| emily | guess we'll have to pin an old version of the alphabet | 01:50:31 |
| Tomodachi94 (they/them) | Don't forget to add it to stdenv! | 01:51:00 |
| Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
I recommend antHook or ant.hook, there is some desire to move away from implicit hooks in general Thinking about this more, this would also mean that we wouldn't need to put this PR into staging (we'd need to put the other refactors in there though), since the Ant package's closure is unchanged | 02:56:21 |
| Tomodachi94 (they/them) | Thus, it's also infinitely easier to review | 02:56:39 |
| Tomodachi94 (they/them) | * Thus, it's also infinitely easier to review (rebuild a few packages vs all 800 dependencies) | 02:57:00 |
| Tomodachi94 (they/them) | * Thus, it's also infinitely easier to review (rebuild a few packages vs all 800 dependencies), so I'll be unblocked faster | 02:58:38 |
