You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, a stage like this will obtain either a value that has directly been passed by a child stage or a value that comes from the global pipeline configuration:
In some cases, we don't want to rely on the global pipeline configuration (because we want to explicitly make sure that this stage is called with a well-chosen argument). Currently, there is no way to enforce a parameter to by passed from another stage rather from global configuration. Therefore, I'd propose to have:
In this case the option becomes a "parameter" to the stage. This requires some moving around of code internally in the pipeline, but should not be awfully complicated.
The text was updated successfully, but these errors were encountered:
I faced an issue where synpp crashes in cases where both parent and child have different setting for a parameter with the same name, e.g. "write_output" is False for child but for parent it is True. This enhancement could also fix it.
Yeah, I guess that it crashes currently is good, as the values should be passed down, and otherwise we get a mix-up. So yes, this could be a solution, because it makes it explicit. And when some config value is a "parameter" we should require that it is passed explicitly. I can have a look at it at some point. Or do you want to give it a try? :)
Currently, a stage like this will obtain either a value that has directly been passed by a child stage or a value that comes from the global pipeline configuration:
In some cases, we don't want to rely on the global pipeline configuration (because we want to explicitly make sure that this stage is called with a well-chosen argument). Currently, there is no way to enforce a parameter to by passed from another stage rather from global configuration. Therefore, I'd propose to have:
In this case the option becomes a "parameter" to the stage. This requires some moving around of code internally in the pipeline, but should not be awfully complicated.
The text was updated successfully, but these errors were encountered: