Is this really the way this is done? You import isrForCrosstalkSources (presumably to get its dependencies and config options) and then exclude it?

Right, I didn't want to touch the main _ingredients file, as long-term the hope is that this short-term workaround will not be required. However, I don't have a feel for how long that long-term fix will be in place, so we needed something that works for now.

My solution here was to leave _ingredients as-is, but exclude the offending task from the user-facing pipeline YAML, and construct a second YAML containing only the offending task.

However, I'm not averse to doing something completely different if you can think of a more optimal approach?

The alternative to the approach on this PR (lets call this PR option a) is to strip isrForCrosstalkSources out of the main _ingredients file and put it either b) into its own _ingredients file, which then gets imported into its own user-facing YAML, or c) just define the task directly in its own user-facing YAML.

I don't have a strong preference for any of these options.

I agree this is weird, but I think if you add an in-line comment explaining why you import a task and then immediately exclude it, all will be forgiven 😄

I agree that this is probably fine as is, provided there is a bit more explanation in the description as to why this is being done and when it can be reverted.

Ah, wait! Apologies, I did not intend to push the #isrForCrosstalkSources - this is a mistake. The power of review for the win.

It should instead just be the main pipeline YAML.

That makes more sense!!

My bad - this section should be (and now is):

imports:
  - location: $DRP_PIPE_DIR/pipelines/_ingredients/DECam/DRP.yaml
    exclude:
      - isrForCrosstalkSources
  - location: $ANALYSIS_DRP_DIR/pipelines/analysis_drp_plots.yaml

I was testing out if you can include only a single task from a YAML (note: you can't), but I forgot to remove my test!

Thanks for picking up on this @fred3m and @mrawls! 🥲