As a user, I want to be able to disable certain plugins

[evgeni]

pulp-cli supports a variety of pulpcore plugins, but currently doesn't have a way to limit the CLI to the ones that are actually installed.

I am not sure whether querying the API before doing anything (including tab completion) is a good idea, but having a way to list plugins that shall be enabled (or disabled, I don't care too much), would be a good middle ground

That way Katello could deploy a config (after #290 is done) where we match the CLI plugins and the Server plugins :)

[mdellweg]

We took the deliberate choice, that both help and shell_completion must not perform any call to the network, so having an option for "aware" installations is the way to go.

I prefer an include_plugins list, because it leaves less room for surprises than exclude_plugins.
Do you think, it should replace the autolookup alltogether and fail if a plugin is missing?

[mdellweg]

Also be aware, that within a plugin the cli might provide commands that will not work with the version of Pulp (core or plugin) you are running.

[ekohl]

I wonder if it makes sense to have a command that does call to the network that tells you which plugins the cli supports, which the server supports. With that info you can trivially build other lists:

• Effective CLI plugins: cli available & server available & include_plugins setting
• Which plugins could be enabled because both cli and server support it: (cli available & server available) - include_plugins setting
• Which plugins are requested but not available on the server: (cli available & include_plugins setting) - server available
• Which plugins are enabled on the server that have no CLI: server available - (cli available & include_plugins setting)

Another factor may be compatibility between cli plugins and server plugins.

[mdellweg]

@ekohl You inadvertantly raise an interesting point here: There is really no technical reason that a cli plugin is corresponding to a server plugin.
In fact, if you think, you have a specific need for a specific subcommand (or you may want to add another output format), and you have a reason to own that code, you can do so by implementing a plugin. (edit: the output format story is not yet quite true... but the idea is there)
Doing set arithmetic with server vs cli plugins would take that away from us.

[ekohl]

I do think that a CLI plugin should declare somehow which server plugin it maps to (or core of course).

[mdellweg]

I do think that a CLI plugin should declare somehow which server plugin it maps to (or core of course).

I think, this can (and it almost is) be done on a per command (-group) basis.
The "file" subgroup already denies to work unless the file plugin is installed.
The challenge here is that we do not want to talk to the server while initializing all the python modules. But i think we can add a second static yet optional source of information to filter commands.

[ggainey]

On reflection, this sounded to me like an anti-pattern for pulp-cli, given its design-goals of "can talk to multiple pulp-servers, all of which have different plugins and different versions". "You have plugin-X installed, but we want it turned off" makes sense for a "captive" env like Satellite...sort of. Even in that env, you might point your CLI to, say, a Capsule at a diff version, or a diff Satellite entirely. Trying to "turn off" specific plugins at the app level feels...wrong.

HOWEVER - even assuming that, on reading through and thinking about the comments - I think there are valuable proposals here, esp things like cli-avail and server-avail. I don't have a design in my head for them, but I think we can use this issue to think about these kinds of requests. I was gonna close this issue, but I'm'a leave it open instead :)