-
-
Notifications
You must be signed in to change notification settings - Fork 718
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
Respect dask.annotate during compute/persist calls #4306
Comments
+1 to having compute-time annotations taking precedence over construction-time annotations |
Agreed
An easy way to do this would be to update existing HLG layers which have their own annotation transmission mechanism. A generic "apply annotations to all keys transmitted to the scheduler" mechanism smells like it may have some gremlins/inefficiencies that would need careful consideration.
Agreed. With the first approach above, this simply involves overriding the existing layer annotations.
If the first approach is acceptable I think I could achieve a quick win. |
I see two possible problems with this:
|
I think I'll take a raincheck on this one as I need to currently work with SchedulerPlugins and scheduling on my side. I am interested in documenting the interaction between Annotations and SchedulerPlugins and have opened an issue to track this: dask/dask#6928 |
Closing as this has been implemented |
Now that dask/dask#6889 and #4279 are in (thanks @sjperkins !) we can use the
dask.annotate
context manager to mark layers built within a contextSome folks may also want to use this same context when calling compute/persist
Some thoughts on how we might do this:
dask.config.get("annotations")
insideClient._graph_to_futures
and then send those annotations up to the scheduler.Scheduler.update_graph_hlg
orScheduler.update_graph
.@sjperkins does this interest you?
The text was updated successfully, but these errors were encountered: