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

Remove 'set' versions of graph phases from top-level cli #612

Open
ahal opened this issue Dec 9, 2024 · 4 comments
Open

Remove 'set' versions of graph phases from top-level cli #612

ahal opened this issue Dec 9, 2024 · 4 comments
Labels
BREAKING CHANGE Backwards incompatible request that will require major version bump

Comments

@ahal
Copy link
Collaborator

ahal commented Dec 9, 2024

Taskgraph allows you to run the generation locally by specifying a phase of the graph generation. Currently these are:

  • tasks
  • full
  • target
  • target-graph
  • optimized
  • morphed

I can't think of any benefit of the tasks or target phases over their counter parts with edges (full and target-graph respectively). So I propose we drop them as cli subcommands (and rename target-graph to target):

  • full
  • target
  • optimized
  • morphed

I think this would make the cli much less confusing without compromising any functionality. The only downside is that generation might take teeny tiny bit longer.

@ahal ahal added the BREAKING CHANGE Backwards incompatible request that will require major version bump label Dec 9, 2024
@ahal
Copy link
Collaborator Author

ahal commented Dec 9, 2024

Or alternatively if the edges are unnecessary when running locally, we could drop full and target-graph, and then rename tasks to full (I feel pretty strongly that the subcommand names should match up to what we colloquially name the phases)

@ahal
Copy link
Collaborator Author

ahal commented Dec 9, 2024

One gotcha here is that we apparently add always_target_tasks between the target_set and target_graph phases. This feels wrong as I feel like those should also be part of the target_set.. but always_target_tasks had a lot of subtle behaviour, so it's possible it needs to be where it is for some reason.

I'm unclear whether keeping the ability to distinguish with/without these tasks on the cli is important or not.. but it's something to consider.

@jcristau
Copy link
Contributor

FWIW I've used both target and target-graph in different cases. target to verify a target_tasks change was doing what I expected, and avoid noise from dependencies. target-graph when I wanted to include dependencies and see the whole thing to be scheduled.

@ahal
Copy link
Collaborator Author

ahal commented Dec 11, 2024

That's a good point.. maybe we could keep target-graph due to that and my previous comment, and only drop tasks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BREAKING CHANGE Backwards incompatible request that will require major version bump
Projects
None yet
Development

No branches or pull requests

2 participants