| 23 Nov 2024 |
 Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
(I drop a lot of packages, so I might make something more generally for dropping packages at some point. We'll see 🙂) I have a prototype for closing issues based on a human feedback loop. I'll post future updates elsewhere | 06:26:54 |
|  Kamilla 'ova joined the room. | 13:19:03 |
| Tomodachi94 (they/them) | Does anyone know how this would affect refactoring the Maven build story to use hooks? https://github.com/NixOS/nixpkgs/pull/313152 | 18:13:07 |
| Tomodachi94 (they/them) | I'm also wondering if we should pin the built-in Maven plugins to versions in Nixpkgs and update them one-by-one instead of with the Maven package. Essentially, introducing a patcher that pins plugins to predetermined versions if they are present in pom.xml, updating them after a Maven update is merged | 18:22:45 |
| Tomodachi94 (they/them) | (Probably would be easiest once the Maven build story uses hooks) | 18:23:17 |
| Tomodachi94 (they/them) | * I'm also wondering if we should pin the built-in Maven plugins to versions in Nixpkgs and update them one-by-one instead of with the Maven package. Essentially, introducing a patcher that pins plugins to predetermined versions if they are present in pom.xml, updating them one-by-one after a Maven update is merged | 18:23:37 |
| Tomodachi94 (they/them) | We would absolutely need to script those updates though | 18:24:41 |
| Tomodachi94 (they/them) | * I'm also wondering if we should pin the built-in Maven plugins to versions in Nixpkgs and update them one-by-one instead of with the Maven package. Essentially, introducing a patcher that pins plugins to predetermined versions if they are present in pom.xml but not pinned, updating them one-by-one after a Maven update is merged | 18:26:16 |
 Morgan (@numinit) | I've gotta figure out a way to automatically build gradle.lock with gradle2nix and the sandbox off | 18:33:24 |
| Morgan (@numinit) | Since gradle feels the need to resolve dependencies lazily, you basically need to run the build before you can run the build 😩 | 18:34:29 |
| Tomodachi94 (they/them) | (Everything would be so much simpler if these build systems just used proper lockfiles 💔) | 18:35:14 |
| Morgan (@numinit) | I tried gradle's lock format and it wasn't proper by any extent, lol. No hashes, no URLs | 18:35:37 |
 emily | we have a Gradle locking solution in the tree with mitm-cache now | 18:36:09 |
| emily | it does just build everything twice though | 18:36:17 |
| Morgan (@numinit) | Oh, cool, I was wondering about that | 18:36:22 |
| emily | it's awful. all Java tooling is so awful | 18:36:36 |
| emily | we really ought to just shim in our own local FS repository and build everything from source but 🙃 | 18:36:59 |
