Separate the Plugin interface into multiple different interfaces for different types of plugins

[ntindle]

Some plugins should only support swapping the Memory, LLM, or UI out. Others may only want to add commands.

We should support these plugins in a way that doesn't require them to update constantly, saying they do or don't support x, y, or z.

The following steps need to be taken to do this:

• Split the Plugin interface into logical sections of (at minimum)

  • Move all Vector Memory Types to plugins #3650
  • Support loading alternate LLMs via the plugin interface #3655
  • Commands
  • prompt generator
  • Embeddings
  • Experience Interfaces
  • Text to Speech

  Longer term:

  • Plugin Manager
  • The workspace -> Exists
  • Config manager
  • resource manager

• Publish these updates to the Plugin Template

• Update all plugins to use these new structures

• Make Installing Plugins Easier #3654

[Boostrix]

regarding commands: it would be useful if there was support for an optional step to prepare commands, but also another step to review the prepared command before it's getting executed. Some users keep seeing nano/vim being used, despite "non-interactive" being a part of their constraints/description.
And in fact, a number of constraints seem to be regularly violated. Thus, splitting command execution into two more stages would help streamline the process:

• preparing the actual command to provide surrounding context, as per: GPT-3 often uses commands incorrectly #2987 (comment)
• retrieving the prepared command for review (to check for constraint violations)
• actually executing the command

[Wladastic]

As a web gui is also being built, we could try adding a setup section where you could also just click and toggle the plugins

[Boostrix]

this seems to be work in progress, according to the logs, commands are going to be moved into plugins and there are going to be ways to enable/disable those individually.

And let's keep in mind that plugin support is a fairly recent addition: #757

What seems to be missing right now (?) is a capabiility for plugins to provide hooks so that these can be separately configured/set up using a holistic interface - at the very least, we need some form get/set interface for key/value pairs, analogous to git.

Apart from dealing with plugin dependencies (#3068), recent efforts are seemingly focused on providing means to explicitly enable/disable individual commands and plugins: #3461

• Enable denylist handling for plugins #3688
• Allow users to Disable Commands via the .env #3667
• Feature/ability to disallow certain shell commands #3707

[anonhostpi]

This should definitely be implemented. Inversion of Control is always a good practice. This would allow the community/end-user to hotswap parts of the codebase with their own implementations. I think the repository should aim to try to achieve this with every part of AutoGPT that is hard-coded into it.

[anonhostpi]

I absolutely love this idea @ntindle

[p-i-]

References PR #2642

[anonhostpi]

So, I've been reviewing all of the repositories Issues and PRs, as well as tracking some of the progress of the re-arch, and I think this PR addresses issues with this repository's IoC.

I started a discussion in GH discussions that addresses poor IoC. Given what I've seen on the 200+ issues I've reviewed over the last 2 days, I think the repo could benefit from the conversation: #3856

I think this PR is a good step in a good direction

[anonhostpi]

needs the https://github.com/Significant-Gravitas/Auto-GPT/labels/re-arch label

[github-actions]

This issue has automatically been marked as stale because it has not had any activity in the last 50 days. You can unstale it by commenting or removing the label. Otherwise, this issue will be closed in 10 days.

[github-actions]

This issue has automatically been marked as stale because it has not had any activity in the last 50 days. You can unstale it by commenting or removing the label. Otherwise, this issue will be closed in 10 days.

[SalesforceBobLightning]

You mentioned updating the plugins, I assume this is 1st party ones, are you also going to update the 3rd party ones too?

[Wladastic]

You mentioned updating the plugins, I assume this is 1st party ones, are you also going to update the 3rd party ones too?

third party plugins are out of our reach, each first party plugin is mostly edited by the original creators and they are mostly responsible, otherwise the plugins are removed from first party.

[github-actions]

This issue has automatically been marked as stale because it has not had any activity in the last 50 days. You can unstale it by commenting or removing the label. Otherwise, this issue will be closed in 10 days.

[github-actions]

This issue was closed automatically because it has been stale for 10 days with no activity.

[Pwuts]

Let's say this is more or less completed by #7054