You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have various commands, that have a special type of parameter Tasks[T], denoting a build target able to produce a T.
Then, we have the very new support for parameters of type Task[T], denoting also a T. T can be specified directly on the CLI, or given as Task[T] or created with T.task(t) programmatically.
Both types essentially describe a T which can also be produces via a task. But currently, there is no way to have a parameter, which supports both ways simultaneously.
Let's take a look at ScalafmtModule. It currently can only format files which are provided by other build targets. It is defined as follows:
Both behave the same on the CLI and accepts the files or directories, but programmatically, the later can be used from other build targets, as all inputs are proper tasks, which don't need to be known beforehand.
So implementation wise, reformat3 is almost identical to reformatAll but provides more flexibility. The only issue with reformat3 on the CLI is, that it won't support other build targets.
Solution
So, here is my idea. What if, on the CLI, we had some marker which denotes a producer of the expected type T. Just as an example, let it be the prefixed colon (:). (I haven't though about a good marker, so please don't hesitate to come up with better suggestions.) Once, we detect such marker, we no longer try to parse the parameter as a T, but we handle it like a Tasks[T]. This means, we parse the parameter as a name (or pattern) to a build task which produces a T.
How could this look like:
# reformat all files below directory src
$ mill reformat3 --sources src
# reformat all files produced by the denoted tasks
$ mill reformat3 --sources :__.sources
We have lots of other commands, which might benefit from this. Essentially, every command could benefit from it, as users typically always do other things with commands or tools in general, than their developers intended. (https://twitter.com/WdeB/status/1482798979511373828)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Motivation
We have various commands, that have a special type of parameter
Tasks[T]
, denoting a build target able to produce aT
.Then, we have the very new support for parameters of type
Task[T]
, denoting also aT
.T
can be specified directly on the CLI, or given asTask[T]
or created withT.task(t)
programmatically.Both types essentially describe a
T
which can also be produces via a task. But currently, there is no way to have a parameter, which supports both ways simultaneously.Let's take a look at
ScalafmtModule
. It currently can only format files which are provided by other build targets. It is defined as follows:To format all source files we can run on the CLI:
But if we want format additional files, we can't. And we already have an open issue for that
To format files or directories freely given on the CLI, we would need to implement a command like this:
or this:
Both behave the same on the CLI and accepts the files or directories, but programmatically, the later can be used from other build targets, as all inputs are proper tasks, which don't need to be known beforehand.
So implementation wise,
reformat3
is almost identical toreformatAll
but provides more flexibility. The only issue withreformat3
on the CLI is, that it won't support other build targets.Solution
So, here is my idea. What if, on the CLI, we had some marker which denotes a producer of the expected type
T
. Just as an example, let it be the prefixed colon (:
). (I haven't though about a good marker, so please don't hesitate to come up with better suggestions.) Once, we detect such marker, we no longer try to parse the parameter as aT
, but we handle it like aTasks[T]
. This means, we parse the parameter as a name (or pattern) to a build task which produces aT
.How could this look like:
We have lots of other commands, which might benefit from this. Essentially, every command could benefit from it, as users typically always do other things with commands or tools in general, than their developers intended. (https://twitter.com/WdeB/status/1482798979511373828)
WDYT?
Beta Was this translation helpful? Give feedback.
All reactions