don't allow loading stages without cmd

[skshetry]

This was loosened when introducing parametrization.
But, foreach..do should be considered first
before the stage's regular structure. And, cmd is made
required (as it should have been)

Related: #5371, #5370, #5312

• ❗ I have followed the Contributing to DVC checklist.

• 📖 If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here.

Thank you for the contribution - we'll try to review it as soon as possible. 🙏

[skshetry]

I'll look into this on later iterations. It should never be empty.

[skshetry]

We might need to move some of the logic in status command to API.

[pared]

This PR contradicts the use case specified in here. I think its not common use case, but still we have been working on 4446 to make it work, @dmpetrov what is the desired behavior?

[skshetry]

@pared, I assumed "dummy stage" being a high-level concept. Could you please elaborate on that?
Do we need to support it in the dvc.yaml file?

[pared]

@skshetry so the dummy stage was supposed to be an empty stage that would only contain params/metrics/plots so that one could trigger default behavior for dvc {params/plots/metrics} show/diff. I am not sure what is the particular use case but it was one of the requirements for #4446 - I guess we need some high-level perspective here.

[efiop]

@pared That's more of a workaround for our current inability to put metrics/etc into the dvc.yaml without creating a pipeline stage. If you remember, we were discussing something like:

data:
- data1
imports:
...
metrics:
- metric1
- metric2
plots:
...   
stages:
....

for the future. Do we need that workaround now? If we do, we could consider proper approach instead of bringing back a hack. CC @dberenbaum

[dberenbaum]

Would metrics optionally have dependencies in the schema above?

[efiop]

Would metrics optionally have dependencies in the schema above?

@dberenbaum Not really. At least we didn't see any need for that yet. Theoretically the proposed schema could be extended with anything under specific metrics entry, but the scenario for declaring metric dependencies without a stage doesn't make sense. The only case where we handle such a thing is in imports as an edge case - if there is one dependency and one output and no command we assume that this is import.

[dberenbaum]

I was assuming that all metrics would be defined at the top level, but it sounds like the idea is to support top-level metrics and metrics defined within stages?

[efiop]

@dberenbaum I was also thinking about that, but not as a new dag in top-level metrics, but more of a high-er level thing, where in stages there are only deps and outputs(e.g. metrics.json is an output) but then at the top level you also declare that this is not only an output but also a metric. But it seems like it is convenient to have support for both options: declare metrics inside of the stages and have an ability to declare them at the top level if they don't have their own stage or choose not to have it.