Hey guys, me again. I'm currently struggling to migrate my private POC project to use pants v2. That POC projects uses most popular libs from Scala world. The problem is that managing dependencies in JVM world is kinda a headache (and it has always been a headache). For example if you run

cs resolve -t org.typelevel:log4cats-slf4j_2.13:2.5.0

for a small library

log4cats

it will already show you conflicts among transitive dependencies (and its a single lib, not a group of them). Conflicts resolution is very very important topic for every build tool that is used for Java/Scala project (if project is not

Hello world

of cause).... I'm pretty sure JVM community will be keen on adopting pants v2 if there was any support for conflict resolution strategy. For example doing something like this would be very helpful.

versionReconciliation ++= Seq(
  "org.typelevel" %% "cats-core" % "relaxed",
  "*" % "*" % "strict"
)

https://www.scala-lang.org/2019/10/17/dependency-management.html Anyways thank u for great tool! Looking forward for new features (heard that

scala_library

is on its way....)

@brave-planet-28195 Hey, thanks for reaching out! This sounds interesting! We use Coursier under the hood to do maven fetching, which means that we can specify requirements as being

strict

— indeed, we use

strict

under the hood to implement lockfiles. Is being able to specify a particular artifact as

strict

sufficient for you, or do you need other reconciliation types? sdo you need anything other than

please checkout this discussion. https://pantsbuild.slack.com/archives/C046T6T9U/p1665011485085219?thread_ts=1665002687.080499&cid=C046T6T9U I think there are problems with

strict-include

...

Out of interest, does manually specifying the conflicting dependency as a

jvm_artifact

help here?

I have project that uses

fs2

,

tapir

,

http4s

,

fs2-kafka

.

cats

,

neotypes

That creates a total mess if run in

strict

mode - this is general problem on conflicts resolution on JVM world - not related to pants. The way to workaround this problem is to provide sane

excludes

for jvm artifacts and compose them with proper versions

By excludes, you mean being able to specify which transitive dependencies to exclude for a given artifact?

for example

cats-core

is real pain... it causes conflicts all over the place. So what i do is this:

jvm_artifact(
    name="cats-effect",
    group="org.typelevel",
    artifact="cats-effect_2.13",
    version="3.3.14",
    packages=["cats.effect.**"],
    excludes=[
        "org.typelevel:cats-core_2.13"
    ]
)

I exclude cats-core from cats-effect

Yeah, that’s definitely how we envisaged it being used (in our initial, best-effort, first implementation)

in general resolving conflicts in codebase that uses alot of libs is hard.... there are few things that I picked up while switching from sbt to pants: 1. When pants (or rather coursier) finds a conflict it seems like the library under conflict will just be removed from classpath. That is done

silently

. Considering the fact that conflicts will happen in transitive dependencies - developer can see errors in runtime

ClassNotFound

. No compile time error.... nothing 2. That's why

conflict resolution

strategy is critical for JVM. For example sbt comes with several conflict resolution strategies. I understand that pants v2 is work in progress and what was already done is great. But for JVM community do adopt tool quicker it would be great to have at list 1 conflict resolution strategy (Strict). That would fail during

check

goal if there are conflicts and display coursier transitive dependencies tree

Right, I understand the need for conflict resolution, just trying to see what the current state of it is

exactly

Would you be willing to commit the broken configuration to a branch? That way I can get an issue written up

My expectation is the following "Ok there could be a conflict in dependencies but my build tool will warn me"

I understand

Instead of warning or error - pants just removed lib under conflict from classpath

That would be great

There is a way to workaround - but you need to be an expert in dependencies ... 😉

But if you can include a link to your repo, with the configuration that behaves incorrectly, that’d be great

Right, does that have the dependency that causes the error?

yeap

ok, great

yeah I can do that

Great, thank you!

Thank you for this!