Spec discussion: How do we want the CLI UX to be for distinguishing a plugin's name and it's type #6222
Replies: 2 comments 2 replies
-
Thanks for starting this @aaronsteers. Here's how things are looking for $ meltano lock --help
Usage: meltano lock [OPTIONS] [PLUGIN_NAME]...
Lock plugin definitions.
Read more at https://docs.meltano.com/reference/command-line-interface#lock
Options:
--all Lock all the plugins of the project.
--plugin-type [extractor|loader|transform|orchestrator|transformer|file|utility|mapper|mapping|extractors|loaders|transforms|orchestrators|transformers|files|utilities|mappers|mappings]
Lock only the plugins of the given type.
-u, --update Update the lock file.
--database-uri TEXT System database URI.
--help Show this message and exit. I like that this make the UX more intuitive, e.g.
|
Beta Was this translation helpful? Give feedback.
-
I'm a fan of this @aaronsteers. It's always been a little odd to me that you have to supply It looks like we already follow this pattern on
Any others? Edit: add |
Beta Was this translation helpful? Give feedback.
-
Following from our conversation on this issue (#6114 (comment)), I wanted to have a formal spec guideline for dereferencing plugins by type (or not) and how that should look in new CLI commands.
As I wrote in that issue:
Having to declare the plugin type unless there's a naming conflict is probably the best path forward for new CLI commands.
This means taking the approach of an optional
--plugin-type
arg to disambiguate if needed and I've includedmeltano config
as the reference example of this approach. The plugin type should be totally optional though, and would only have a function to (1) confirm the type is as expected if the user wants to be explicit, and (2) resolve ambiguity if two plugins of different type have the same name. (Although we should consider name collisions illegal in a future meltano version.)We should in general be encouraging plugins to not have name collisions. They already cannot have them within a specific type, and would need to be aliased if so.
Related: in future, we're talking about reducing the total number of plugin types so that a broad category of utility plugins would have
capabilities
likeanalyzer
,validator
,orchestrator
, etc., but those may not always be distinct plugin types. Hence, keeping extractor type out of our default CLI convention is a good thing overall. (E.g.meltano config tap-gitlab
preferred overmeltano config extractor tap-gitlab
, andmeltano lock tap-gitlab
preferred overmeltano lock extractor tap-gitlab
.)Beta Was this translation helpful? Give feedback.
All reactions