Add Ability to overwrite task settings when calling a task in Functional API
See original GitHub issueCurrently, a common pattern is:
t = MyTask(name="test task", tags=["A"])
with Flow() as f:
res1 = t(1)
res2 = t(2)
...
and each individual copied instance of the task will appear with the same name "test task"
in the UI and any other place that information is surfaced.
To allow for more nuanced control of the copying of tasks, we should add a reserved kwarg _task_args
to task call signatures which allow for overriding things (such as name
) when calling / copying the task.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:5 (5 by maintainers)
Top Results From Across the Web
RunTask - Amazon Elastic Container Service
You can override the default command for a container (that's specified in the task definition or Docker image) with a command override. You...
Read more >Tasks in Visual Studio Code
Integrate with External Tools via Tasks. Lots of tools exist to automate tasks like linting, building, packaging, testing, or deploying software systems.
Read more >Working with TaskFlow — Airflow Documentation
This tutorial builds on the regular Airflow Tutorial and focuses specifically on writing data pipelines using the TaskFlow API paradigm which is introduced...
Read more >Jobs API updates | Databricks on AWS
To overwrite the settings of a multi-task format job, specify a JobSettings data structure with an array of TaskSettings data structures. See ...
Read more >The Anatomy of a Prefect Task
When the run method of your task is called, it is executed as Python code. ... How might we add a single task...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think this feature is going to add a lot of utility to
FunctionTasks
(and the@task
decorator more broadly) because it will allow those tasks to be reused without having to rewrite them. Currently, to use the same@task
-decorated function as a task with two different retry behaviors, you have to rewrite the decorated function just to change the retry value. With this kwarg, you could affect the same behavior much more cleanly. I’d vote that this is a very explicit form of controlling behavior and should have a very explicit implementation.Good point 👍🏻👍🏻