| 17 Sep 2025 |
 Tomodachi94 (they/them) | Other ant PRs of mine that could use some love and are less weird than this one:
- https://github.com/NixOS/nixpkgs/pull/357162
- https://github.com/NixOS/nixpkgs/pull/357162 (fixing the merge conflicts)
| 01:53:29 |
 msgilligan | The second bulleted item links to the same PR as the first. | 02:26:30 |
| msgilligan | I asked for one minor change to 357162. | 02:26:54 |
| msgilligan | And once 443476 one is merged, we can remove Oracle GraalVM 24:
https://github.com/NixOS/nixpkgs/pull/443634 | 03:11:23 |
| Tomodachi94 (they/them) | Oops, my bad. Here's the right one: https://github.com/NixOS/nixpkgs/pull/359137 | 03:41:10 |
| Tomodachi94 (they/them) | (And a bunch of good reasons for doing this: https://github.com/NixOS/nixpkgs/issues/357758) | 03:41:55 |
| Tomodachi94 (they/them) | Also add that the original ant-contrib has had no updates since... 200[4-9] iirc? | 03:43:24 |
| Tomodachi94 (they/them) | (There are some active forks that we could package if anything in-tree ends up needing it) | 15:21:15 |
| Tomodachi94 (they/them) | * | 16:43:09 |
| msgilligan | There's probably some Java interoperability component that is built with Ant. Ideally these things would be in separate derivations with Swift and Ant as inputs, right? | 18:27:57 |
| msgilligan | graalvm-oracle_25 is now the default graalvm-oracle. PR to drop graalvm-oracle_24 is ready-for-review:
https://github.com/NixOS/nixpkgs/pull/443634 | 18:30:02 |
| msgilligan | emily is always quick to review/merge the PRs that drop JDKs 😁 | 18:30:43 |
 emily | my weakness… | 18:41:42 |
| emily | wow beaten to it… | 18:41:58 |
| msgilligan | I view it as a strength! | 18:42:43 |
| msgilligan | I'm hoping that getting the new versions merged earlier will help us get the old versions removed faster. | 18:59:46 |
| msgilligan | I fixed the nixpkgs-vet error about new top-level package using pkgs.callPackage in the zulu25 PR: https://github.com/NixOS/nixpkgs/pull/443517/commits/f65e6c648d89794fc801d95280355dcca779f990 | 19:54:01 |
| msgilligan | This is my first time refactoring usage of callPackage so I'm not sure I did it right, but it looks reasonably clean and seems to work, so please take a look and let me know if I got it right. | 19:56:19 |
| emily | you can inherit ({ zulu8 = callPackage …; … }) zulu8 …; | 19:56:35 |
| emily | (yes it's silly) | 19:56:37 |
| msgilligan | in the new default.nix? That seems more verbose, is there an advantage to doing it that way? | 19:58:47 |
| emily | no, in all-packages.nix | 20:00:53 |
| emily | it's just the officially-sanctioned hack for when there is an existing multi-version package outside of by-name | 20:01:04 |
| msgilligan | Oh, I see other instances of this patter in all-packages.nix. I'll fix it! | 20:02:59 |
| msgilligan | So like this:
inherit (callPackage ../development/compilers/zulu { })
zulu8
zulu11
zulu17
zulu21
zulu23
zulu24
zulu25
;
zulu = zulu21;
?
| 20:10:10 |
| emily | what i mean is you don't need the default.nix at all | 20:13:25 |
| emily | https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/README.md#recommendation-for-new-packages-with-multiple-versions | 20:14:02 |
| emily | you can literally just inherit ({ … }) …; in all-packages.nix | 20:14:12 |
| emily | it is silly, but it is the sanctioned workaround | 20:14:23 |
| emily | the "nice" solution is to do a version-generic package in by-name like I did for OpenJFX but it's more work | 20:14:38 |
