I also want to add that by pushing in this direction we may create the opposite problem: it will become hard to find all tasks that belong to a given library/framework. For example, if we adopted this pattern, phoenix tasks could spread over multiple namespaces and then trying to understand what Phoenix provides and how Phoenix affects a project becomes trickier.
So I agree with Eric, I prefer to keep the tasks under the parent namespace and then build my own meta tasks with aliases. *José Valimwww.plataformatec.com.br <http://www.plataformatec.com.br/>Founder and Director of R&D* On Tue, Dec 12, 2017 at 10:23 AM, Eric Meadows-Jönsson < [email protected]> wrote: > 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/ms >> gid/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-%3D2ZSWgMfhWshsRVYdaNuW9aUraFyk > Hz8Rrw%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAM_eaphBLvQ61F-%3D2ZSWgMfhWshsRVYdaNuW9aUraFykHz8Rrw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAGnRm4LMM%2BQPWvKvk3D9dmOP2%2B%3DvLUa%2BJnAXZVmRaOCMFqE20A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
