| 28 Nov 2024 |
 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 |
| emily | (I know, I know, but I gotta keep beating the drum…) | 06:12:43 |
 Tomodachi94 (they/them) | (I wonder how much effort it would take?) | 19:57:09 |
| Tomodachi94 (they/them) | We could introduce mavenRepository attrset which exposes JARs with Maven-friendly paths (many build systems speak Maven, including Maven, Gradle, and Ivy). The packages would just be derived from ones that are in the mainspace (or another namespace; maven.plugins could be one) | 19:59:07 |
| Tomodachi94 (they/them) | The idea would be to symlinkJoin the packages and then pass the path to whichever build system | 19:59:33 |
| Tomodachi94 (they/them) | In other news: I have a fully built-from-source version of Ant locally (with the exception of three censored JARs that I intend to build from source) | 20:00:58 |
| Tomodachi94 (they/them) | * In other news: I have a fully built-from-source version of Ant locally (with the exception of three vendored JARs that I intend to build from source) | 20:01:05 |
