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

stem: provide validate functionality #150

Open
oliver-sanders opened this issue Jul 12, 2022 · 2 comments
Open

stem: provide validate functionality #150

oliver-sanders opened this issue Jul 12, 2022 · 2 comments
Milestone

Comments

@oliver-sanders
Copy link
Member

Rose Stem sets some Jinja2 variables on install.

These variables are not present when trying to validate the source which makes workflow development awkward. I don't think we can "detect" rose-stem workflows because what makes them rose-stem workflows is being installed with rose-stem. Consequently I don't think we can make cylc validate play nicely by default.

We should try to do something to make stem workflow development nicer.

Pull requests welcome!

@oliver-sanders
Copy link
Member Author

Cylc Rose allows cylc validate, cylc graph, &c &c to access rose-suite.conf prior to workflow installation.
Rose stem cannot be used to validate a rose-stem suite.

Either by adding a rose stem --validate option, or by adding a --stem argument to the options available in Cylc enable validation, graphing &c of rose stem suites.

@oliver-sanders
Copy link
Member Author

It's a bit too rose suite-run to go adding an option for each command e.g. --validate, --graph, --config to rose stem to support each individually.

I think we should go for a more generic solution which handles all of them. I can see a way of doing this, however, there is one barrier which is how to handle the special rose stem command line options i.e. --graph, --task, --source. I don't like the idea of adding these options to the Cylc command line. We could use the existing template variable interface e.g. --group='["foo", "bar"]', however, this would be as convenient e.g. --group=foo,bar.

More thought needed...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant