com-lihaoyi
Remove CoursierModule#mapDependencies
This PR removes CoursierModule#mapDependencies altogether, and uses CoursierModule#resolutionParams instead. mapDependencies is hack that the coursier API allows, but it's too powerful IMO. A benefit of using resolution params instead is that almost anything done via resolution params can be done via the coursier command-line, which is handy to debug things.
As we have users of this API, a discussion how to replace it, would be nice. E.g. my main usage is:
- Replace some transitive dependencies (change coordinates, e.g. replace some logging impl with a different impl; switch from non-osgi to separately released osgi artifact)
- Bump or enforce transitive versions
Bump or enforce transitive versions
You should use CoursierModule#resolutionParams for that. https://github.com/com-lihaoyi/mill/pull/5070/commits/eb223b64c6dc54393e353df79a69584a775bcd8a illustrates that.
Replace some transitive dependencies (change coordinates, e.g. replace some logging impl with a different impl; switch from non-osgi to separately released osgi artifact)
Is that use case that widespread? AFAIR, no one asked for this in coursier, or in the context of its use in sbt.
As of now, there's no out-of-the-box replacement for that. If you know the dependency you want to replace is pulled, you can exclude it from the other dependencies, and add the one you're interested in alongside those.
If you're unsure if it's pulled, it might be more complicated. You may want to resolve the dependencies pulling the wrong one in a dummy module, and depending on whether these pull the wrong dependency, do like just above.
Replace some transitive dependencies (change coordinates, e.g. replace some logging impl with a different impl; switch from non-osgi to separately released osgi artifact)
Is that use case that widespread? AFAIR, no one asked for this in coursier, or in the context of its use in sbt.
Probably not so widely required, but more often needed than anticipated. (The list of examples was not complete.) There is a reason why I choose Mill over other build tools. When I had to manage such scenarios with Maven, I used a tool (cmvn) that generated Maven projects, so I was able to configure module-wide exclusions, which were rolled out to every dependency. Exclusions aren't a nice fit, as you can't express them module-wide. You can roll them out programmatically, but that still gives you a large unmanageable tree.
As of now, there's no out-of-the-box replacement for that. If you know the dependency you want to replace is pulled, you can exclude it from the other dependencies, and add the one you're interested in alongside those.
This is costly work and more importantly, it produced hard to maintain setup, since you fix symptoms and don't express the intent.
Thing is, mapDependencies might be a hack, but it was added for a reason and it is there and works. You "think" it is too powerful, ok, but should we remove it? We could document it as advanced and discourage use, ideally list the issues it produces. Currently, the downsides are totally unclear to me.
When "enterprise" software with hundreds of modules and dependencies gets maintained/audited, you sometimes have to mangle some specific dependencies. Be it the exclusion of some vulnerable but unused classes or any other unthinkable task, and you can't always use a latest version or whatever. You also can't publish every hack into some repository to consume it, and falling back to unmanaged dependency is a death sentence. Powerful ways to mangle the dependency tree without loosing all the other standards is what makes Mill the greater alternative to Maven and Gradle.
