New Plugin Interface

[norman-abramovitz]

What's the user value of this research request?

The CLI Plugin interface has not been upgraded for multiple years. The technology has changed, so we should reconsider how plugins can be integrated into the CLI. This research issue will capture the various design ideas for the CLI Plugin Interface.

The end goal of this research is an RFC for the selected methodology that can be implemented by mid to late 2026, given the CAPI V2 API's end of life.

Who is the research issue for?

• This research issue provides a place to capture the desires and requirements for plugin users.
• This research issue provides a space to capture the desires and requirements of plugin developers.
• This research issue provides a place to capture the desires and requirements from the CLI maintainers.

Is your research request related to a problem? Please describe.

• The current plugin interface is dependent on archived code.

• The current plugin interface depends on unmaintained code.

• The current plugin interface has been frozen in time.

• The current plugin interface has not been published to Go's packages website since November 2019.

• The current plugin interface has not kept up with changes in the Go language.

• The current plugin is overly dependent on the CLI command's internals.

• The current plugin interface does not provide sufficient versioning support as the CLI command version changes.

• The current plugin interface does not provide sufficient build information.

• The current plugin interface does not provide sufficient release information.

• The current plugin interface does not provide a maintainable path to support other development languages.

• CLI maintainers no longer maintain the current plugin interface.

Describe the various solutions you'd like
TBD
Describe alternatives that could be considered

• Do nothing
• Drop support for a plugin interface.
• Provide PRs to the CLI maintainers to integrate the plugin functionality into the CLI command.
• Use the CLI version commits to build with the appropriate CLI version.
• Provide independent wrapper functions for the existing CLI plugin interface.
• Have the CLI commands generate human and machine-readable output.
• Hashicorp Plugin model
• GitHub Plugin model

Additional context Please add any additional context or screenshots related to the research request here.

Note:
As of the GA of the v7 CLI, the v6 line is no longer under active development and will be updated only to patch CVEs or fix severe blocking defects with no workarounds.

Grammarly was used to help write this description.

[jcvrabo]

my 2 cents

The plugin interface is not inadequate per se, it abstracts the api domain from the plugin while providing easy access to environment context to have context based queries (i.e., allows querying the current org and space the user currently is in and allows doing queries by object names based on the namespace (service instance and app names, for example).

One could argue that the main important data one gets from the cliConnection provided through the cli is the accessToken, ssl flag, current org and current space. In fact, independently updating plugins to v3 is based just on that, using the token to create a cli client and querying the cliConnection to get the current org and space... after which the v3 api can be directly queried to retrieve whatever information may be required. However, this will make plugins directly dependent on the capi and breaking changes will effectively break the plugins, while plugins relying on the interface the cli provides will rely on the cli being updated to continue to get the same information.

That being said, I would say that the model from the plugin interface should perhaps be revisited and make it more efficient, now that the app/summary endpoint is gone (for example) and design a more intuitive and modular domain and api.

On top of that, revisiting the libraries and the communication interface would also be advised, prune out old libraries, perhaps simplify the dependencies (sometimes an import becomes a burdened convenience) and although a bit out of scope, that would apply to the cli itself, where old libraries are still being used, and I would even question if it would not be better to use standard libraries already available and maintained by the community (like for network policies or capi clients).

[norman-abramovitz]

Would I say CLI plugin interface is 'inadequate'. Probably, only because

1. Some plugin developers did not notice or care that the plugin interface was not being updated.
2. Plugin developers had to find their own solutions how to update their plugins to work with CLI V7, CLI V8 and CLI V9
3. The CLI development team was stalemated on what to do with the CLI plugin interface.
4. The CLI plugin interface was not updated when CVE's existed in the framework or built plugins.
5. The CLI plugin interface has dependencies on archived or unmaintained packages.
6. The public community cli plugin repo became unusable because many of the published plugins were not being maintained or provide sufficient information for clients to decide if the plugins are safe to be used.

All your other points we agree on and I look forward finding common ground how to modernize the CLI plugin infrastructure and development.

[parttimenerd]

Especially the outdated libraries were a real hassle when I started maintaining the cf-java-plugin. Compared to other plugin frameworks, it's also notable that every plugin has to roll out its own option parsing framework, leading to inconsistencies between plugins and making maintenance more challenging.

[beyhan]

I'm discussing this topic with the plugin maintainer on our side, who has already added support for CF API v3 and had to use the "minimal" interface mentioned in the comments above. Based on our discussions, I think we can come up with a concrete proposal. If we reach agreement on that, the next step would be to create an RFC out of it.