Replies: 2 comments 3 replies
-
|
I'm totally open for this idea. It's great. I even though about that myself, but didn't find the time to actually work on it. Unfortunately, changing the signature of For a start, we could just add a new (experimental) command. I think, we could fix this issue by supporting a command options class as single parameter which can be handled by |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Turns out, delegate classes are already supported and should be the preferred way to write commands in Mill, as it ensures, command arguments can be evolved. |
Beta Was this translation helpful? Give feedback.
-
|
So, instead of def ivyDepsTree(
inverse: Boolean = false,
withCompile: Boolean = false,
withRuntime: Boolean = false.
+ whatDependsOn: Option[String] = None
): Command[Unit] = ???we should prefer something like def ivyDepsTree(args: IvyDepsTreeArgs): Command[Unit] = ???
class IvyDepsTreeArgs private (
val inverse: Flag,
val withCompile: Flag,
val withRuntime: Flag,
val whatDependsOn: Option[String]
)
object IvyDepsTreeArgs {
def apply(
val inverse: Flag = Flag(),
val withCompile: Flag = Flag(),
val withRuntime: Flag = Flag(),
val whatDependsOn: Option[String] = None
) = new IvyDepsTreeArgs(inverse, withCompile, withRuntime, whatDependsOn)
}
implicit val argsReader: mainargs.ParserForClass[IvyDepsTreeArgs] = mainargs.ParserForClass[IvyDepsTreeArgs]
|
Beta Was this translation helpful? Give feedback.
-
|
Just to tie these all together, this was implemented in #2191. |
Beta Was this translation helpful? Give feedback.
-
I find
ivyDepsTreeincredibly useful. However one missing feature that I find myself reaching for is the--what-depends-onthat coursier offers. I'll give you a real world example of what this could be used for, and an idea of how I'd implement it.An illustration
So I use mill-dependency-submission to submit deps to GitHub and I recently wanted to check out where gson was coming from in mill-giter8. So I did the following:
mill plugin.ivyDepsTree --withCompile true
However this is a crazy huge output. So you have to
| grep gsonor something like that to even find where gson is in this huge tree. Coursier provides a nice feature to trim this down to the part that you're actually interested in. For example with the above, gson ends up coming in through ammonite, which itself is brought in through mill-main-core. You can see this easily with coursier by doing:A much much smaller more digestible tree. It'd be awesome to be able to do this with Mill alone.
Potential solution
I think we could maybe change the signature of
ivyDepsTreeto the following:def ivyDepsTree( inverse: Boolean = false, withCompile: Boolean = false, withRuntime: Boolean = false. + whatDependsOn: Option[String] = None ): Command[Unit] = ???Then we could steal some code from Coursier and do basically exactly what they do when we call
coursier.util.Print.dependencyTree:You can see this code in Coursier here. Then you'd be able to do something like
❯ mill plugin.ivyDepsTree --withCompile true --whatDependsOn com.google.code.gson:gsonBeta Was this translation helpful? Give feedback.
All reactions