Regarding Result locations vs targets: I understand having the Task's

target

override a Result's

location

as the former is more specific to a Task. Laura mentioned keeping them separate for the purposes of having the task caching be more opt-in behavior, but I don't understand how providing a templated string to

location

doesn't also qualify as that behavior. Is there opposition to having a Result's

exists

method check for the passed in variable if there is one, and also check for

self.location

?

Hi @jorwoods - thanks for the question! I think most of the core team who would have views on this are out this afternoon. I'll ask one of them to get back to you when they are back at their computer.

Thanks @Jenny! Yeah, this seemed potentially controversial, so I thought I had better ask rather than just write the code for it

Hey @jorwoods as I see it, targets serve to complement features that users may have used in other systems in the past. A templated string in the Result's location as it stands now doesn't check for existence and will overwrite the data found at that location. I believe targets seek to function as "I expect data to exist here" and write it if not. IIRC we had some discussion around this around the time of implementation and you can read about the decisions in the PIN https://docs.prefect.io/core/PINs/PIN-16-Results-and-Targets.html Hopefully that answers it in some way and I encourage anyone else to chime in 🙂

Thanks for the context, @josh. I read the PIN a few times, but it still wasn't overly clear that there was intent behind the decision to not use Result's as a checkpoint. (I am in the midst of trying to transition off of Luigi, as context for my frame of reference.) I guess the added confusion was the deprecation of Task's cache_validator, and addition of validators into

Result

. Are the validators on Result then there to ensure the proper item was written out upon task completion, rather than to ensure the result is still valid upon next run? Or is there some other use of a Result's validators that I am missing? Also trying to figure this out as sometimes I may want to manually rerun the flow sometimes in a scenario where it ignores all existing cache, and reproduces everything. I think that may be a common enough need, that I would like to contribute it back to core if possible rather than writing an external utility to handle it.

The use of cache validation on Results is still an open issue that is planned to be implemented in an upcoming release! Would you be willing to comment on this issue with your thoughts for visibility? https://github.com/PrefectHQ/prefect/issues/2619

Aha! Will do. This issue seems to describe exactly what I was considering. I will move the discussion there.