| 19 Jul 2025 |
 vog | The s6 tool do perform this job perfectly. | 20:35:03 |
 emily | we do have NixOS containers for that, but they are moderately heavyweight | 20:35:18 |
 Infinidoge 🏳️⚧️ | In reply to @emilazy:matrix.org
right, NixOS modules are quite bad about being unnecessarily singleton Entire reason behind nix-minecraft lmao | 20:35:30 |
| Infinidoge 🏳️⚧️ | Being able to host Exactly One minecraft server sucks | 20:35:54 |
| vog | Ok, but back to you original quesion: No, I don't neet a module configuration, just a pkgs configuration. But why were you asking? | 20:36:28 |
| emily | unfortunately the module system is kind of bad (my hot take) | 20:36:33 |
| emily | (but the things we do with the module system are nice) | 20:36:47 |
| emily | do wish we had something that didn't make singletons the happy path | 20:37:02 |
| emily | because manual containerization sucks | 20:37:10 |
| vog | Ok, so I'm now back where I started. Many alternatives, but none of which appears interesting of even feasible to me. So I'd like to add junixsocket. | 20:39:36 |
| vog | Crazy idea: What if we make junixsocket, perhaps just the two parts "junixsocket-common" and "junixsocket-native-common", a dependency on postgresql_jdbc? That way, every Nix package that uses pkgs.postgresql_jdbc would automatically have support for unix sockets. | 20:41:12 |
| Infinidoge 🏳️⚧️ | Not particularly crazy, a lot of packages do stuff like that, only skipping it if the optional dependency os extremely heavy | 20:41:57 |
| Infinidoge 🏳️⚧️ | * Not particularly crazy, a lot of packages do stuff like that, only skipping it if the optional dependency is extremely heavy | 20:42:15 |
| vog | So would it make sense if I propose a pull request for exactly that? Or would that be doomed to be rejected? (In which case I'd work on a less intrusive solution instead) | 20:43:03 |
| Infinidoge 🏳️⚧️ | Most PRs are usually doomed to inactivity instead of rejection | 20:43:37 |
| Infinidoge 🏳️⚧️ | This change makes perfect sense to me so I say go for it | 20:44:00 |
| vog | I'm a bit confused about java package conventions, though. So continuing my list of questions: | 21:32:58 |
| vog |
- Java libraries are not meant to be added to javaPackages, at least libraries like postgresql_jdbc and jogl are not. Is this intentional, or a bug?
| 21:33:42 |
| vog | 3 .Java libraries are put into by-name/.../, contrary to what is usual in other languages within Nix (e.g. ocamlPackages, etc.). Should I follow that convention? | 21:34:59 |
| vog | *
- Java libraries are put into
by-name/.../, contrary to what is usual in other languages within Nix (e.g. ocamlPackages, etc.). Should I follow that convention?
| 21:35:09 |
| vog |
- If a package provides github binary release tarballs, should I prefer those, or should I prefer fetchMavenArtifact?
| 21:46:34 |
| vog | *
- Java libraries are not meant to be added to javaPackages, at least libraries like
postgresql_jdbc and jogl are not. Is this intentional, or a bug?
| 21:47:17 |
| Infinidoge 🏳️⚧️ | In reply to @vog:matrix.org
- Java libraries are put into
by-name/.../, contrary to what is usual in other languages within Nix (e.g. ocamlPackages, etc.). Should I follow that convention?
Java libraries are a bit different because they aren't notably intertwined with each other, while languages like ocaml and python have a very intertwined library ecosystem | 21:55:35 |
| Infinidoge 🏳️⚧️ | Java libraries are treated by and large like normal packages both in Nix and elsewhere | 21:55:59 |
| Infinidoge 🏳️⚧️ | In reply to @vog:matrix.org
- Java libraries are not meant to be added to javaPackages, at least libraries like
postgresql_jdbc and jogl are not. Is this intentional, or a bug?
As far as I can tell javaPackages only has openjfx nowadays, and that will likely be moved out later on when separated from the jdk itself | 21:57:58 |
 msgilligan | I was just curious and thought it might be good to have some context. | 22:55:05 |
| vog | Thanks! Regarding my last question, I decided to prefer fetchMavenArtifact, for the simple pragmatic reason that it allows me to easier reference to the sub libraries (junitsocket-common, etc.) separately. | 22:56:48 |
| vog | * Infinidoge 🏳️⚧️: Thanks for your responses! Regarding my last question, I decided to prefer fetchMavenArtifact, for the simple pragmatic reason that it allows me to easier reference to the sub libraries (junitsocket-common, etc.) separately. | 22:57:19 |
| Infinidoge 🏳️⚧️ | Makes sense to me | 22:57:32 |
| 21 Jul 2025 |
|  Pol joined the room. | 15:50:24 |
