Interactive recipes can't be executed in automated workflows. There should be a way for the recipe to know if it is being executed non-interactively, and act accordingly. Now this is crudely possible already by using environment variables, i.e.
But is it worth adding better support for this? For example, all interactive expressions could have a fallback property, which would be used if the environment is non-interactive (basically, the command should get an error if they try to connect to an IO interface in such an environment, falling back to their fallback). Detecting whether the environment is non-interactive can be done via multiple ways: a flag (such as --force), environment variables for popular CI/CD pipelines (see this), etc. This could also result in a predetermined environment variable being automatically set, basically standardising the env var solution outlined above.
Interactive recipes can't be executed in automated workflows. There should be a way for the recipe to know if it is being executed non-interactively, and act accordingly. Now this is crudely possible already by using environment variables, i.e.
But is it worth adding better support for this? For example, all interactive expressions could have a
fallbackproperty, which would be used if the environment is non-interactive (basically, the command should get an error if they try to connect to an IO interface in such an environment, falling back to their fallback). Detecting whether the environment is non-interactive can be done via multiple ways: a flag (such as--force), environment variables for popular CI/CD pipelines (see this), etc. This could also result in a predetermined environment variable being automatically set, basically standardising the env var solution outlined above.