These are chat archives for sbt/sbt
A relaxed chat room about sbt (That interactive build tool). For getting help on sbt, we encourage people to document it on Stackoverflow or subscribing to Lightbend subscription.
Settingclass made it easy to write internal methods, but tying it with all the setting keys values is a bit tedious. I was just curious if there is a better or at least more idiomatic way to achieve the same thing, i.e. tying multiple settings with an internal model.
Settings. But if anything that's less idiomatic..
i heard that SBT's ivy-resolution behavior is configurable and can be made to mimic Maven's; is this true? Is there any documentation about this?
Furthermore, I heard (from @jodersky, iirc) that SBT and Maven's Ivy resolution differ in that SBT takes the version of an artifact that is latest across all occurrences in the transitive-dependency tree, while Maven takes the version that is closest to the top of the tree (i.e. if my project declares a dependency on Foo v1, that will be used even if some of my deps use Foo v2, since my project is the top of the dependency tree). Is that accurate?
force(), which emulates nearest-wins
an interesting wrinkle to semver-based heuristics: minor-version-upgrades cannot cause any new code paths in dependencies to be hit (without risking the same kinds of RTEs that major-version-upgrades can cause).
semver is not obviously super clear on this from my reading:
MAJOR version when you make incompatible API changes,
that doesn't really seem to cover this scenario
MINOR version when you add functionality in a backwards-compatible manner
this could be interpreted as covering this scenario, but most ppl don't seem to interpret it that way, and the "MAJOR version" rule seems to miss it…
i mean, my dream-dep-manager will fall back to building from source against the deps that a given project needs, like the spark-notebook example i showed:
the important thing is too be able to turn caching off at any point
why do you say that?
@OlegYch probably superfluous at this point, but here's an example repo verifying nearest-wins vs latest-wins in maven vs sbt https://github.com/ryan-williams/maven-sbt-ivy-resolution
maybe at the least it will add some pagerank points to eugene's links above :)
however, i guess i still have my original issue: i heard that SBT could be configured to use Maven-style resolution.
I see that it can use the ivy conflict mgrs here: https://github.com/sbt/sbt/blob/v0.13.13/ivy/src/main/scala/sbt/IvyInterface.scala#L43-L50
but i don't see Maven's "nearest-wins" anywhere!
poking around, i don't see coursier obviously supporting "nearest wins".
i think i agree with you that strict is not usable and that version ranges and semver can't really save us.
i don't think the "nearest wins" heuristic is so unreasonable though, and seems like a fine complement to the "latest wins" heuristic; SBT's
dependencyOverrides hooks seem to validate the use-case, and i've only recently become aware of them, so it's possible i'll be able to use them to get out of tricky situations in the future