| 27 Nov 2024 |
 Tomodachi94 (they/them) | For those interested, there are a few other refactors waiting to enter the pipeline (a few are prerequisites for building from source, one is for consistency with other distributions' packaging of Ant):
| 04:22:19 |
| Tomodachi94 (they/them) | For those interested, there are a few other refactors waiting to enter the pipeline (a few are prerequisites for building from source, one is for consistency with other distributions' packaging of Ant):
https://github.com/NixOS/nixpkgs/pull/358204 https://github.com/NixOS/nixpkgs/pull/357162 (still WIP) https://github.com/NixOS/nixpkgs/pull/359137
| 04:22:39 |
 Infinidoge 🏳️⚧️ | Fair warning, I'm currently on break and it's coming up to the end of the semester, so I likely won't respond unless pinged, and I've set my github status to let people know I'm busy | 07:41:54 |
| Tomodachi94 (they/them) | Good luck with your studies! 🚀 | 19:25:42 |
| Tomodachi94 (they/them) | shakes fist at clouds Who loves a circular dependency between Ant and xz-java? :3 | 22:53:51 |
| Tomodachi94 (they/them) | (there's probably a way to solve it with a hypothetical ant.bootstrap package) | 22:58:39 |
| Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
shakes fist at clouds Who loves a circular dependency between Ant and xz-java? :3 I bet there's more hiding in the dependency chain 🙃 https://github.com/NixOS/nixpkgs/issues/353512#issuecomment-2504960268 | 23:18:01 |
| Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
To hardcode or not to hardcode the path to the Ant executable in the hook, that is the question Choosing to not do so allows us to use the hook to build Ant itself | 23:19:41 |
 emily | I don't think most hooks hardcode that | 23:21:09 |
| 28 Nov 2024 |
| Tomodachi94 (they/them) | @Toma I'm wondering if we should close https://github.com/NixOS/nixpkgs/pull/355153 and wait until Maven 4 is released? Maven changes the defaults of some knobs like outputTimestamp to be reproducible by default | 05:36:39 |
| Tomodachi94 (they/them) | @Toma I'm wondering if we should close https://github.com/NixOS/nixpkgs/pull/355153 and wait until Maven 4 is released? That version will change the defaults of some knobs like outputTimestamp to be reproducible by default | 05:36:54 |
| Tomodachi94 (they/them) | (Pinging Toma because he's done a bunch of work on Java determinism and also reviewed that PR; others welcome to chime in, of course) | 05:39:04 |
| Tomodachi94 (they/them) | * (Pinging Toma because they've done a bunch of work on Java determinism and also reviewed that PR; others welcome to chime in, of course) | 05:40:59 |
| Tomodachi94 (they/them) | I think that depends on when they're planning on releasing Maven 4. We could also include the upstream patch until then | 05:42:18 |
| Tomodachi94 (they/them) | * I think that depends on when they're planning on releasing Maven 4. We could also include the upstream patch(es) making reproducibility the default until then | 05:42:36 |
 Toma | I haven't looked into maven4 yet, so I don't have an opinion abot that yet. | 05:46:00 |
| Toma | Not very related but what I would like to happen sometime in the futute is that we try to figure out how to handle the default lifetime plugin issue with maven.
It's good and all that we have a FOD, but it's horrible that the hash changes every time maven is updated. | 05:46:22 |
| Toma | Maybe bundle the version-defaults with maven, and remove those from the FOD.? | 05:47:00 |
| Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
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 I proposed this up here | 05:47:33 |
| Tomodachi94 (they/them) | * I proposed something related up here | 05:47:40 |
| Tomodachi94 (they/them) | In reply to@tomasajt:matrix.org
Maybe bundle the version-defaults with maven, and remove those from the FOD.? That seems like the ideal path. Or maybe having them in separate packages that expose Maven repository-ish paths | 05:49:07 |
| Tomodachi94 (they/them) | * I proposed something related up here (don't know if it would work) | 05:50:18 |
| Toma | In reply to @tomodachi94:matrix.org
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 An alternative would be to just pin maven for every package.
Very simple solution, but not very pretty.
Though, I doubt the plugin patching solution would be much prettier. | 06:00:39 |
| emily | to an exact minor version? | 06:01:31 |
| emily | or just a major version? | 06:01:36 |
| Toma | Exact version | 06:01:52 |
| emily | I don't think we want/can sustain that level of version proliferation | 06:02:04 |
| Toma | You're right, it would just delay the inevitable manual re-pinning in the future | 06:03:56 |
| Toma | By the way I have a package that uses mill as the build system (IIRC it's the only one in the tree), which also fetches jar files from Ivy. What's much worse about that is that we can't pin any internal plugin versions, like with maven. As a solution I just locked the version of mill.
Not sure if there was anything better I could have done. | 06:09:33 |
| emily | you know, you don't have to deal with FOD stability issues if you just build everything separately from source :) | 06:12:37 |
