feat: remove requirement for `PLUGIN_TYPE` positional arg in CLI commands `meltano add`, `meltano remove`, `meltano install`

Currently in the CLI only the meltano add and meltano remove commands require you to specify the plugin type.

Other commands default to just referencing the name while enabling a user to specify --plugin-type if necessary. Commands that accept --plugin-type:

• invoke
• lock
• config

Proposal

Drop the requirement for <type> when using meltano add and remove so that users can type:

meltano add tap-gitlab or meltano remove target-postgres and Meltano can just figure that out. When there is a collision a we can error out, tell the user there are multiple plugins with that name present and have them disambiguate.

When a user is adding a --custom plugin, we can infer the type from the name (pattern match on tap and target) and/or prompt them for a type. We should likely just ask is this an extractor, loader, or a non-connector (utility).

[aaronsteers]

What about the top-level index here:? hub.meltano.com/meltano/api/v1/plugins/index It includes a ref for all variants, as well as the name of the default variant. We’d have to page through the types, but locally that iteration would be pretty quick.

@aaronsteers yeah that’d probably be faster, if still pulling more data than it needs.

Thanks for confirming. Agreed it’s perhaps slightly more than needed, but at least not an order of magnitude greater. One option for the future optimized version would likely take some search parameters like ‘plugin name’ and perhaps offer pagination if the resultset is too large. But that said, not being static, I don’t know if the optimized version would be much faster even if returning less data. 🤷 (We can analyze+discover when we get there. 😄 )

[edgarrmondragon]

What about the top-level index here:? hub.meltano.com/meltano/api/v1/plugins/index

It includes a ref for all variants, as well as the name of the default variant.

We’d have to page through the types, but locally that iteration would be pretty quick.

@aaronsteers yeah that’d probably be faster, if still pulling more data than it needs.