Throw an exception if a UUID is defined in default configuration [#2201501]

Problem/Motivation

Follow-up from #2110615: Do not ship with default UUIDs. We've removed the expectation that UUIDs should be in default configuration as well as the usecase they were intended to support (deploying configuration between arbitrary sites) in favor of having a single site UUID. So, if a module does provide a UUID in a default config file, we need to decide what to do with it.

Proposed resolution

There are three options:

Throw an exception.
Ignore it.
Respect it and install with that UUID.

Throwing an exception would be best because it avoids the problem of accidentally supported usecases that got us into the UUID snafu in the first place. :)

Remaining tasks

Patch needed.

API changes

Shouldn't be any.

Comments

Comment #1

sun

German

Karlsruhe

CreditAttribution: sun commented 20 February 2014 at 17:53

I do not see why we need to care so aggressively or even throw an exception. The one and only point of default config is:

Here are some parameters to create a brand new entity.

By design and by definition, every new entity/resource gets a new UUID.

→ "Ignore it" in the sense of "force-create a new UUID".

Right now, you can simply copy a config file from your active config directory to your extension's default config directory, which is great a DX/UX for module developers, as well as installation profile authors.

I don't see why we should make that any harder than it needs to be?

Throwing an exception in case of a UUID in a default config file would be the one and only reason for having to manually open and edit the config file after copying it, even though the value is semantically meaningless in the first place. Doing so needs a very good reason for why we'd be substantially degrading the DX/UX of creating default config.