-
-
Notifications
You must be signed in to change notification settings - Fork 596
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
RFE: Allow use of wildcard or regex in task names (dynamic task names) #836
Comments
Using regular expressions would open up a whole raft of complex edge cases, purely because regular expressions are so powerful. I suspect there'd also be some funky encoding issues (esp around Allowing a simple Just to toss out one possible approach ...
There would still lots of edge cases to solve, not least of which is what should happen if multiple tasks match. E.g. what if you had tasks:
Start*:
# ... elided...
*Stop:
# ... elided ...
Limbo:
deps: [StartDoorStop] What does the task Possible answers include:
I think I can make a convincing argument for all five of these choices. What about when the match is empty? tasks:
Disco:
deps: [Start] Does the task Whichever answers are picked, they need to be documented - and Task needs to give good diagnostics so that people aren't left scratching their heads in disbelief. |
I am inclined to advise making "found multiple matches" as well as "no matches" a runtime error, just to avoid confusions like you described. This could also play well with an option that would allow minor typos in task names based on their name, like In fact That is why I am biased toward regex, as it does open the door for more complex patterns in the future and capture groups, something globbing will never allow. Obviously that for first implementation we should only support simple regex pattern matching (no capture groups). |
Quoting in YAML is straightforward.
Where did I suggest that? Anyway, globbing is really simple to implement - pass the string to |
I really miss this feature of Makefiles: update-foo::
update-bar::
update-baz::
update-%::
$(MAKE) -C pkg/$* update |
will this feature be added to the roadmap in the future? it's really awesome! |
Would be great to have, as
|
In order enable taskfile to a viable replacement for some more specialized test runners, such tox or nox, we need to allow it to accept task names that are using a pattern (regex or glob), so users would not have to copy/paste task definitions when creating test-matrixes.
A very easy to explain example is that tox accepts tasknames like
py
,py36
,py311
without forcing user to explicitly define each value. The idea is that the variadic part of the name ends-up as being processed as a variable.In fact its support for this goes even deeper allowing you to use multiple dimensions and have tasks like:
py36-func
, py36-unit`, all without having to define an endless list of combinations.While supporting multiple dimensions might be seen maybe as too much for taskfile, maybe we should at least allow user to define a taskname like
foo*
and ensure that the effective taskname is available inside a variable. That should allow someone to process the name and infer the matrix variables to use for it, or give an error message if the arguments are not valid.While the glob version (
py*
) would be easier to implement, the regex would be more flexible as it would allow to validate the task name and even document allowed inputs, likepy(\d+)\-((unit|func))
. Using capture groups we can also extract the dimensions, if using named capturing groups we could even determine in which variables we could save them.The text was updated successfully, but these errors were encountered: