Recipes have no way to tell if they're set up for success

Yes, some dry-run before actually applying a recipe and show whether it can be applied or not and why it can't be applied.

A little update here.

A while ago, I spoke to @alexpott about this. He told me what his vision of this is, and if I understood him correctly, it's basically the opposite of preconditions. In other words: let's have a set of conditions that, if they are all true, mean the recipe has, in effect, already been applied. To put it another way: if all of the conditions check out, then your site is already in the same state that the recipe would have put it into.

We could glean this information already, using the information we already have. If:

• everything in the install list is already installed; and
• everything in config.import exists in the active config storage, and looks identical to what the recipe would have installed; and
• everything in config.actions has been done (config action plugins would probably need a new method, or a specialized add-on interface, to determine this programmatically)...

...then the recipe doesn't need to be applied. Everything it was going to do, has been done already.

For the sake of discussion, let's call these the recipe's "fulfillment conditions".

Now, let's take it further and suppose that a recipe could, if it wanted to, define an explicit set of fulfillment conditions, instead of relying on the system to try and figure it out. Maybe we'd have some kind of syntax in recipe.yml which allows a recipe author to state, "these are the conditions under which this recipe should be considered fulfilled." That would allow the recipe to be more lax, or more strict, in determining whether it's been fulfilled.

You'd think, then, that if we're in the middle of applying a stack of recipes, any recipe that is not already fulfilled should presumably be applied, overwriting whatever config already exists. But that's quite dangerous, because in such a situation, even a slight deviation from the default fulfillment conditions would result in the site's config getting silently blown away. I believe this is what the maddening \Drupal\Core\Recipe\RecipePreExistingConfigException thrown in ConfigConfigurator was intended to prevent.

So if we go down this road and try to implement the concept of fulfillment conditions, maybe what we should do is keep our current behavior, where even the slightest difference between the recipe's config and the active config stops the recipe from being applied...but the fact that a recipe can specify its own fulfillment conditions means that there is an out for recipe authors, who can now say something like -- to use a contrived example -- "don't worry if the anonymous user role already exists and looks different; if it exists at all, consider this recipe fulfilled".

I hope this makes sense. Curious to get thoughts on it.

Kubernetes doing the same with manifests, I can't find ATM the code but I'm sure it using very similar approach

phpunit calls this PreConditions. Drupal module requirements have install time check as well.

Adding #3463641: Create a way for recipes to check their preconditions → as related and possibly not needed.

From @bircher in Slack.

I think they are not duplicates.. or at least the comments mean that they could go in different directions and we could have both.

A) A way to say "sorry this recipe can not be applied, abort"
B) A way to say "this recipe is happy, consider it applied and continue"

A is useful when you want to prevent a recipe messing things up, or you don't have a recipe to depend upon that would set things up for the recipe in question to "just work"

B is useful for recipes that are used as a dependency of others.

But that said maybe we can close the second one because we try to make the config actions more lenient and so there is not that much of a need? although we probably then also could debate whether we need a conditionalConfigUpdate in addition to simpleConfigUpdate because the later will override any customisation a site builder may have added.