Open lefou opened 5 years ago
I think all those tasks should not be Task
s. That means:
Essentially, I'd like them to be "dumb" main/entrypoint methods. If they need to do stuff with the Evaluator
, they can take an Evaluator
instance and call evaluate
themselves.
Do we want to support an Evaluator
magic task parameter at all? How do we want to contribute (by plugins) tasks like mill.scalalib.GenIdea/idea
in the future?
I think Evaluator
would need to not be a magic-task-parameter, but a magic-main-method-parameter; we can set up the implicits so tasks and main methods can share most of the command-line deserializers, but can also have some that are unique to each (though for now I can only think of Evaluator
)
mill.scalalib.GenIdea/idea
would be a main-method rather than a T.command, and users could define their own in their build.sc or in ExternalModule
s
To call a main-method via cmdline, we need some proper syntax.
As buildfiles and external modules are just valid Scala, there should be no name collision when using the same syntax as for targets. When parsing the cmdline, we need to decide if the first parameter is a main-method or a target. But I have no idea how to elegantly solve this for built-in mains like clean
, all
, etc. Without some prefix or namespace, the user would expect those to be either targets or main-methods in build.sc
.
mill mill.scalalib.GenIdea/idea
refers to a main-method or target in an ExternalModule
named mill.scalalib.GenIdea
. mill my-cmd
refers to a main-method or target in a buildfile build.sc
A magic Evaluator
parameter is only accepted, if the def is not a target but a simple scala method (aka main-method).
How could we map built-ins to avoid name collisions:
mill.clean
, mill.version
, mill mill.all t1 t2
mill --clean
, mill --version
, mill --all t1 t2
mill --clean
, mill -v
, mill --par t1 t2
, mill -seq t1 t2
I like the mapping to options, either generic/automatic or manual. This would be more idiomatic in the sense of same-as-in-other-tools.
When parsing the cmdline, we need to decide if the first parameter is a main-method or a target.
I think for now we can assume there is only one method/target/etc. of the same name in the same module.
While Scala allows you to overload things, and you can have e.g. multiple T.command
s of the same name but different parameters, a lot of our code assumes we only have one-thing-per-name. I don't even know what happens if there are overloads, but I assume it doesn't treat it elegantly.
So for now, no need to worry about naming collisions; that's an orthogonal issue to changing the semantics of main methods and can be fixed separately.
But I have no idea how to elegantly solve this for built-in mains like clean, all, etc. Without some prefix or namespace, the user would expect those to be either targets or main-methods in build.sc.
They can always ask:
lihaoyi mill$ mill inspect clean
[1/1] inspect
clean(MainModule.scala:196)
Deletes the given targets from the out directory. Providing no targets
will clean everything.
Inputs:
lihaoyi mill$ mill inspect release
[1/1] inspect
release(build.sc:455)
Inputs:
publishVersion
dev.runClasspath
This is no different from any other "where did i inherit something from" question, which is an existing issue separate from main method semantics.
How could we map built-ins to avoid name collisions
Again, this is an existing problem, so no need to fix it in the context of this issue. We've already discussed this, and I'm inclined to leave things in the same namespace for now. We can move forward on the things we agree on (changing main method semantics to allow parallelization) without waiting for consensus on unrelated things (cleaning up namespaces) that we can continue to discuss
See https://github.com/lihaoyi/mill/pull/480#issuecomment-436927941 and https://github.com/lihaoyi/mill/issues/491#issuecomment-444006357
Currently,
all
,show
,resolve
,clean
and other built-in tasks take an evaluator instance and are part of the task graph itself, which is somewhat in-elegant. They take part of caching, force the existence of theout
folder (even theclean
task) and trigger dependency resolution. Also, the interaction and ordering in case of parallel task execution is unclear.