https://pantsbuild.org/ logo
Join Slack
Powered by
Hey! I had a quick look at potentially supporting ...
# development
f
Hey! I had a quick look at potentially supporting BOM files for Scala dependencies. It is particularly useful for really tangled dependency-trees like the Google API clients, where it is really painful to maintain compatibility manually. Using their BOMs is what they recommend to avoid dependency-hell. I then saw that Coursier got support for BOM files for resolving dependencies very recently, so got to thinking that maybe it could actually be possible to support in Pants since we use coursier to resolve them already? WDYT, worth digging into a bit more?
Not really sure how a sensible way to specify dependency artifacts with like 
version = fromBOM
might look like. So just curious if anyone have any general thoughts/input on something in that direction
f
Is there a particular file format for specifying BOMs?
I think we'd want to think about the potential UX for a feature like this.
Some ideas (not exclusive of each other): 1. Config option mapping resolve name to one or more "BOM files" (if such a format exists) 2. Add an appropriately-defined 
dependency_management
field (or better name) to 
jvm_artifact
if BOMs can be specific to transitive dependencies of an artifact. 3. Define a new target type for collecting such dependency management BOMs.
I imagine pom.xml files count as BOMs if they have a 
dependencyManagement
section?
f
Yeah exactly, here's pretty much the gist of what you would like to be able to specify in some way https://cloud.google.com/java/docs/bom#maven I think it would be nice to be able to add artifacts as usual, but then specify some kind of 
dependency_management
as you said, with some BOM-option where you can say "use this BOM to determine the version for these dependencies". And then still be recorded in the pants-lockfile etc as normal when resolved 🤔
And
Bazel doesn't support BOMs.
for Scala yet so we could be first 😄. They also noted the door opening with coursier adding support https://github.com/bazel-contrib/rules_jvm_external/issues/229#issuecomment-2586170409
f
Ah so the BOM is a particular kind of JVM artifact.
f
Yes exactly, that can be referred to as a source for determining versions of the actual dependencies. Such that upgrading "google-clients" becomes upgrading the BOM, instead of all of the many libraries, pretty much
Maybe something like this could be fair
Copy code
jvm_bom_artifact(
    name="libraries-bom",
    artifact="libraries-bom",
    group="com.google.cloud",
    version="26.55.0"
)

jvm_artifact(
    name="google-cloud-storage",
    artifact="google-cloud-storage",
    group="com.google.cloud",
    versionFrom=":libraries-bom"
)
The coursier requests must be run per each distinct bom, but they can be provided directly on the same resolve path like
Copy code
coursier fetch --bom com.google.cloud:libraries-bom:26.55.0 com.google.cloud:google-cloud-storage: --json-output-file=./coursier.json
So it might be quite reasonable to implement
Or maybe all BOMs can even be provided in a single fetch and then let coursier deal with conflicts, even simpler
6 Views
Open in Slack
PreviousNext
Powered by