Settings/capabilities can't be overridden locally for plugin added from the hub with incomplete metadata

See https://github.com/meltano/meltano/issues/2717#issuecomment-1146363583 and @edgarrmondragon’s response.

It means that adding a plugin from the Hub with missing/incorrect metadata leads to user to a bit of a dead end, as they won’t be able tweak the capabilities and settings in their own project to find out what works 😬 They could directly edit the lockfile, but I don’t think we want users to actually do that.

There needs to be a way to for a user to try out metadata changes locally to get the plugin working, before they can contribute them to the Hub, and it doesn’t look like there currently is.

We didn’t have this issue with meltano add --custom, because that would always add a full plugin definition (with a namespace) to meltano.yml that didn’t inherit anything from the Hub or discovery.yml and would allow capabilities and settings to be set.

[DouweM]

@aaronsteers Yep that’s right!

[DouweM]

@aaronsteers wrote:

Sounds like a bug:

those properties [capabilities and settings] were only respected on fully custom plugin definitions with a namespace, not on those that inherited from discovery.yml … and … the lockfile.

Presumably would be resolved by https://github.com/meltano/meltano/issues/3296

@aaronsteers I don’t think that was a bug, but rather intended behavior: either settings/capabilities are inherited (no namespace), or they are defined in-line (with namespace). Making namespace optional may fix this in the process, but there would still need to be a way to say “don’t inherit a plugin definition at all, I’ll provide all metadata inline”, which is currently indicated by the presence of namespace.