-
-
Notifications
You must be signed in to change notification settings - Fork 60
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
Comments
This parameter would be a redundant feature. For you it will make the syntax Let me try to explain the reasoning of the design. First of all, the used term This covers the classic "task dependency" scenarios
but it is not limited to them. For example, in this case
it is not quite right to say Also, you can do something "crazy" (if you need, of course):
This is also good for potential future changes. For a given task X with jobs, So the syntax is driven by the concept of flexible jobs instead of the rigid If you like you may use the parameter name |
In other words, different concepts require different parameters. A task in psake is a named list of dependencies and one action where A task in Invoke-Build is a named list of jobs where jobs are task references |
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 |
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.The text was updated successfully, but these errors were encountered: