| 24 Nov 2024 |
 emily | I'll try and look some time tonight | 00:08:06 |
 Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
I'll try and look some time tonight No rush if I was too soon | 00:14:08 |
| emily | no worries :) | 00:15:20 |
| Tomodachi94 (they/them) | Currently hunting for packages that provide Ant task providers and adding a symlink in the spot expected by ant.hook | 01:57:58 |
| Tomodachi94 (they/them) | Found a few thanks to nix-index. Will PR that in later | 04:34:52 |
| Tomodachi94 (they/them) | (Also, there are so many packages that have Ant in their output, but don't need it to be there) | 04:38:51 |
| Tomodachi94 (they/them) | Wondering if we should drop the programs.java NixOS module, since it's impure and only has two in-tree consumers (packages should make a wrapper that calls jdk/jre, developers should be using devShells) | 22:25:12 |
| Tomodachi94 (they/them) | Pinging @FliegendeWurst @chayleaf @Infinidoge 🏳️⚧️ for input | 22:28:18 |
| Tomodachi94 (they/them) | Pinging @FliegendeWurst @chayleaf @Infinidoge 🏳️⚧️ for input (others welcome to chime in too, of course) | 22:28:37 |
 Infinidoge 🏳️⚧️ | The main benefit of the Java module is that it let's end consumers emulate a more standard Linux distribution for running programs that use Java internally, so I don't think it being impure is strictly a reason to remove it in this case | 22:30:00 |
| Infinidoge 🏳️⚧️ | At minimum though in-tree consumers can be rewritten away from it | 22:30:25 |
| Infinidoge 🏳️⚧️ | * The main benefit of the Java module is that it lets end consumers emulate a more standard Linux distribution for running programs that use Java internally, so I don't think it being impure is strictly a reason to remove it in this case | 22:30:41 |
| Infinidoge 🏳️⚧️ | It's a similar position to nix-ld, albeit less critical | 22:31:27 |
 FliegendeWurst | The binfmt hooks seem only marginally useful to me. The .class one only really works if the class depends solely on its own package. | 22:34:11 |
| Tomodachi94 (they/them) | For starters I'll add it to our ci/OWNERS section, then we can change in-tree consumers to the makeWrapper pattern later | 22:36:37 |
| Tomodachi94 (they/them) | https://github.com/NixOS/nixpkgs/pull/358840 | 22:55:02 |
| 25 Nov 2024 |
| Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
I'm going to look into which of our packages use Gradle 7 and try updating or submitting patches for a newer Gradle, to hopefully make the future deprecation of Gradle 7 smoother Made a tracking issue for this, so our future drop+upgrade can go much smoother than the gradle_6 one: https://github.com/NixOS/nixpkgs/issues/358845 | 00:11:01 |
| Tomodachi94 (they/them) | * Made a tracking issue for this, so our future drop+upgrade can go even smoother than the gradle_6 one: https://github.com/NixOS/nixpkgs/issues/358845 | 00:31:03 |
 Ami | In reply to @tomodachi94:matrix.org
Wondering if we should drop the programs.java NixOS module, since it's impure and only has two in-tree consumers (packages should make a wrapper that calls jdk/jre, developers should be using devShells) i haven't looked at what it does or what needs those changes, but i do use plain java commands at times, sometimes for development, sometimes to run some jar that most likely doesn't have a nixpkgs equivalent | 01:53:28 |
| Tomodachi94 (they/them) | In reply to@ami:the-apothecary.club
i haven't looked at what it does or what needs those changes, but i do use plain java commands at times, sometimes for development, sometimes to run some jar that most likely doesn't have a nixpkgs equivalent Looks like the Jenkins and Bloop modules only afaict | 02:03:22 |
| Tomodachi94 (they/them) | I'll probably update those later tonight, along with updating packages which have patches released for Gradle 8 | 02:15:27 |
| Ami | speaking of running plain java commands, is there any "good" way to use multiple java versions in the same environment, or at least get something similar to that? the most obvious answer to me seems like using nix-shell in one way or another | 02:23:14 |
| Tomodachi94 (they/them) | In reply to@ami:the-apothecary.club
speaking of running plain java commands, is there any "good" way to use multiple java versions in the same environment, or at least get something similar to that? the most obvious answer to me seems like using nix-shell in one way or another I don't think there's anything built-in, but my first thought was somehow prefixing the executables. Symlinks maybe? | 02:25:10 |
| Tomodachi94 (they/them) | (We could also introduce "prefixed" packages; we have one for coreutils for example, so it's not unprecedented) | 02:25:44 |
| Tomodachi94 (they/them) | * I don't think there's anything built-in, but my first thought was somehow prefixing the names of the executables. Symlinks maybe? | 02:26:18 |
| Ami | in terms of what i'd prefer to type in my shell, it'd be something like java8 -jar whatever.jar | 02:28:46 |
| Infinidoge 🏳️⚧️ | Python type beat | 02:58:10 |
| Infinidoge 🏳️⚧️ | While it would be slightly unorthodox to include in the base package, I think it would be nice to support | 02:59:42 |
| Infinidoge 🏳️⚧️ | Maybe we could Be The Change and convince JDK to start doing this in general | 03:00:00 |
|  @nullcube:matrix.org joined the room. | 09:59:00 |
