| 1 Jan 2025 |
 linsui | So that the mitmCache package will be smaller? | 16:47:47 |
 emily | it won't include the broken Postgres | 16:51:23 |
| emily | not sure :/ | 16:51:48 |
| emily | it uses some srcOnly stuff | 16:51:49 |
| emily | it may be harmless to have the mitmCache entries though | 16:51:49 |
| emily | I think patching the Gradle file is the correct way in any case | 16:51:50 |
| linsui | Yep :) | 16:53:14 |
| linsui | How should I deal with transit deps of it? I need to package https://github.com/zonkyio/embedded-postgres and remove the dep of the embeded pg binaries. But it has other maven deps. | 18:18:52 |
| linsui | * How should I deal with transitive deps of it? I need to package https://github.com/zonkyio/embedded-postgres and remove the dep of the embeded pg binaries. But it has other maven deps. | 18:19:31 |
| emily | ah, I think I misunderstood: I thought you wanted to replace some Java PostgreSQL binding it used with one we already have packaged in Nixpkgs (as part of the PostgreSQL package, say) | 18:19:59 |
| emily | but this is a library that embeds and spawns Postgres itself? | 18:20:05 |
| emily | that's unfortunate, I wonder if we can convince the library to use our own Postgres… | 18:20:24 |
| linsui | Yes, it packages pg binaries in its deps. | 18:20:32 |
| linsui | With patches we can do anything. :) | 18:20:47 |
| emily | re: transitive deps, I think you should be able to just use our standard Maven builders? I believe those work in the usual FOD hash way and you could inject that into jabref | 18:20:58 |
| emily | but I'm not entirely sure. Java dependency handling is a mess and I don't trust it. | 18:21:08 |
| linsui | It unzip the pg binaries into a tmp dir and run it. I'll patch it to run pg from nixpkgs. | 18:21:45 |
| emily | in true Java fashion, the library has an interface PgBinaryResolver. maybe you could patch jabref to implement that interface and use it, and skip patching the library entirely | 18:21:53 |
| linsui | And this lib will use the implementation provided by jabref? | 18:26:03 |
| emily | I think it depends on how jabref uses the library :S | 18:26:51 |
| emily | you can pass a PgBinaryResolver to EmbeddedPostgres | 18:27:10 |
| emily | if it uses EmbeddedPostgresRules.singleInstance() I think you need to do something like new SingleInstancePostgresRule().customize(builder => builder.setPgBinaryResolver(…)) instead | 18:28:41 |
| linsui | Ah, I understand now. :) Thanks! This is a good idea! | 18:30:09 |
| emily | ideally the library would just let you set an environment variable or something to give it a prebuilt Postgres but I guess this is more Java 😅 | 18:30:54 |
| linsui | I tried to find such a env var but it seems there is no such thing... | 18:31:39 |
| emily | the closest thing I can find is that it includes the distro name when looking for the tarball which it looks up in some kind of Java classpath resources thing … but I don't know if you can inject into that without patching the library | 18:32:30 |
| emily | https://github.com/zonkyio/embedded-postgres/blob/ed189edde855b25340245b7fac5a7fe6a5a497a6/src/main/java/io/zonky/test/db/postgres/embedded/DefaultPostgresBinaryResolver.java | 18:32:41 |
| emily | logger.error("No postgres binaries found, you need to add an appropriate maven dependency " +
"that meets the following parameters - system: '{}', architecture: '{}' " +
"[https://github.com/zonkyio/embedded-postgres#additional-architectures]", system, architecture);
| 18:32:53 |
| emily | it seems like maybe you could construct a fake package just to provide our own PostgreSQL, in a way that this can find | 18:33:07 |
| linsui | I guess I need to package the pg binaries into a txz file then put it into a jar... | 18:37:51 |
