Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task dependency syntax clarity #26

Closed
michael-baker opened this issue Jul 6, 2016 · 3 comments
Closed

Task dependency syntax clarity #26

michael-baker opened this issue Jul 6, 2016 · 3 comments

Comments

@michael-baker
Copy link

I've picked up Invoke-Build after considering psake, Cake etc
I like that it supports incremental building which is a key feature of a build orchestration engine. I also like that it isn't a module so it won't pollute my PowerShell runspace or bleed variables back into the caller.

However, I have a minor gripe with the task dependency syntax. Currently I have to define a task and dependencies like so

task Foo Bar, { }

This is very nice and concise, but awkward at the same time. The trailing , to create an array is a bit unfortunate.

Would it be possible at add an optional parameter to specify dependencies like psake has with -depends? I feel this will help other maintainers of my scripts grok them more effectively without the somewhat magical syntax confusing them.

@nightroman
Copy link
Owner

nightroman commented Jul 6, 2016

This parameter would be a redundant feature. For you it will make the syntax
"better". For some other users it may be confusing. A redundant feature, as
such, may exist. But there must be really good reasons for it.

Let me try to explain the reasoning of the design. First of all, the used term
"task dependency" is not quite right for Invoke-Build tasks. Unlike other tasks
runners, it uses the original (perhaps unique) concept of jobs, where jobs are
task references and own actions in any required order.

This covers the classic "task dependency" scenarios

task Foo Bar, { }

but it is not limited to them. For example, in this case

task Foo { }, Bar

it is not quite right to say Foo depends on Bar, because Bar is invoked
after the own action of Foo. The task Bar is a post task, continuation.
Such cases are less frequent but they exist and they are supported.

Also, you can do something "crazy" (if you need, of course):

task Main Task1, { }, Task2, { }, Task3

This is also good for potential future changes. For a given task X with jobs,
you may move its action to a separate task and replace it with this task
reference. Or a task reference may be replaced with an action. Or you
may reorder, add, remove jobs. In any case, the syntax of X does not
change, just its job list changes.

So the syntax is driven by the concept of flexible jobs instead of the rigid
approach task -depends -action. The syntax also turns out to be concise,
which is probably good, but this was not the goal at all.

If you like you may use the parameter name -Jobs explicitly to emphasize
that its argument is an array and commas are expected. It is just a matter of
time to get used to the syntax and think in terms of "jobs", not "dependencies".

@nightroman
Copy link
Owner

nightroman commented Jul 6, 2016

In other words, different concepts require different parameters.

A task in psake is a named list of dependencies and one action where
dependencies are task references. So it reflects this concept by two task
parameters, Depends and Action. (It also has PreAction and PostAction).

A task in Invoke-Build is a named list of jobs where jobs are task references
and actions in any required number and order. So it reflects this concept by
one parameter, Jobs. It would be unnatural to support an extra parameter
Depends just because another tool uses it due to the different concept.
(Note that PreAction and PostAction are also covered by Jobs).

@michael-baker
Copy link
Author

Thanks for the detailed reply. It covers off concept of jobs nicely and the subtle differences compared to dependencies in other task system. I'll try out -Jobs anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants