Skip to content
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

internals: task "output" vs "message" #6001

Open
hjoliver opened this issue Feb 28, 2024 · 1 comment
Open

internals: task "output" vs "message" #6001

hjoliver opened this issue Feb 28, 2024 · 1 comment
Labels
code refactor Large code refactors
Milestone

Comments

@hjoliver
Copy link
Member

hjoliver commented Feb 28, 2024

For historical reasons the naming of data structures and variables associated with task outputs and prerequisites is a bit confusing:

  • originally task outputs were task messages, full stop
    • consequently tasks messages are the fundamental thing stored as outputs and prereqs in the code
    • and they are usually called "outputs" because they function as outputs
  • then we added short names for use as triggers in the graph
    • these got variously called output "names", "labels", or "triggers", and sometimes "outputs"

So that's all a bit confusing. And now, for Cylc 8, the way we talk about optional and required outputs elevates the importance of the short names.

We should:

  1. check that "output" always refers to the short name, in the docs
  2. ensure that naming in the code is consistent with this
  3. and possibly change the internals to store the short outputs as the fundamental entities rather than the task messages. The translation can be done first thing on receiving incoming messages
@hjoliver hjoliver added the code refactor Large code refactors label Feb 28, 2024
@hjoliver hjoliver added this to the some-day milestone Feb 28, 2024
@hjoliver
Copy link
Member Author

hjoliver commented Mar 14, 2024

Expanding on the above a bit, the way task outputs are stored in the TaskOutputs class is quite ungainly. (3 overlapping dicts: _by_trigger, _by_message, and _required). I'm sure this could be reduced to one simple data structure, particularly if we switch to using only outputs (as opposed to messages) internally.

@hjoliver hjoliver mentioned this issue Mar 14, 2024
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code refactor Large code refactors
Projects
None yet
Development

No branches or pull requests

1 participant