Compile needs a meta task because the compilers have a common interface, they affect each other and need to be wrapped up in task. The compile task does more than just run all tasks in the compile.* namespace.
The rest of the functionality you mention seems like they can be solved by aliases which should be more flexible. What do we gain by wrapping them up in meta tasks instead of using aliases? On Tue, Dec 12, 2017 at 4:54 AM, Christopher Keele <[email protected]> wrote: > There is a certain category of mix task that I think we can offer better > tooling and automatic discovery for. This type of task is rarely > parameterized, normally namespaced as a subtask, and generally serves as a > setup/teardown step for a library at the filesystem level. I think of these > as 'project lifecycle hooks'. Some examples include: > > - new: create source files locally > - get: retrieve files across the network > - compile: create necessary code artifacts within the build folder > - build: create artifacts not necessary for the execution of the project > or library's other tasks > - clean: remove artifacts that this library owns from the above 3 steps > - install: place files in a location such that they auto-enable some given > functionality > - uninstall: remove files from such locations > > Many libraries offer these sorts of task under their namespaces. The way > these setup/teardown tasks work, I often find myself wishing that I could > run all of a certain type at once as a sort of common 'phase' when > interacting with a project. For example: > > - before starting a parallelized CI run I want to `compile` everything I > can into a cached build folder > - after passing a test run I want to produce all artifacts like project > documentation, escripts, hex packages, test and documentation coverage > reports, and the like > - after thinking I've fixed a warning emitted somewhere during compile > time I want to force `clean` *everything* out so I can see a > comprehensive list of remaining warnings > > The `compile` task is a good example of elixir already sort of supporting > this today. It's a simple meta-task that runs all `compile.xxx` tasks based > on the `:compilers` configuration inside the project mix.exs. > > I think we should run with this idea of a meta-task to the other lifecycle > tasks. Optionally, I think we should allow for automatic discovery of them > (such that configuration within the mix.exs is not required). > > The proposal is simple: define a set of task names that should exhibit > this behaviour, specify exactly what they should be responsible for as a > guide to task implementers, and create meta-tasks for them that will > enumerate the subtasks within their namespaces. > > Libraries that want to opt-in to this framework can simply start naming > their tasks under the appropriate meta-task namespace (ie. `mix > build.dialyzer`) instead of their own (`mix dialyzer.build`). > > Users that want to add existing tasks to a meta-workflow from libraries > that have not opted in can just specify an alias in their mix.exs to place > it within the namespace (ie `aliases: [{"clean.dialyzer", > "dialyzer.clean"}]`). > > Of the examples I listed above, `get` and `new` do not make much sense to > run in bulk, as in order to discover other potential `get` tasks you need a > compile phase after `deps.get`; and `new` is normally parameterized and > rarely idempotent. `install` and `uninstall` also are generally specific > one-off commands. > > However, bulk compile, build, and clean tasks correspond elegantly to CI > cache, on-success, and cache-cleaning phases respectively. If a common > Elixir build script was defined in terms of these batch meta-tasks, it > would be invaluable for projects that add or remove tooling, since their > setup documentation and CI builds would keep working without modification. > > Such meta-task tooling could be a starting point for identifying and > unifying other common project lifecycle tasks across the ecosystem. I can > envision a `report` meta-task separate from `build` that exists to produce > human-readable reference files (like docs and test/documentation coverage > reports) separate from machine-readable artifacts like PLTs, escripts, and > hex packages; or a `push` meta-task that publishes hex packages, updates > 3rd party code coverage sites, or triggers webhooks. > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/elixir-lang-core/cb7c4267-ffac-4a5c-a03d- > 91bcdaa52809%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/cb7c4267-ffac-4a5c-a03d-91bcdaa52809%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Eric Meadows-Jönsson -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM_eaphBLvQ61F-%3D2ZSWgMfhWshsRVYdaNuW9aUraFykHz8Rrw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
