… classes (#4764) ### Motivation and Context This PR solves two works items: #4560 and #4667. The Python SDK had different ways of handling plugins and collections. The work in the PR helps align the SDK with dotnet nomenclature and structure.  ### Description A `KernelPluginCollection` is introduced with an underlying `DefaultKernelPlugin` and a `KernelPlugin` base class. Other code is refactored to use this new `KernelPluginCollection` model which should simplify how plugins are handled. Unit tests are added to test the new functionality. Existing unit tests and integration tests, along with kernel examples and notebooks were updated based on these changes. Unlike before, we're requiring plugins to be defined with a name, which removes the GLOBAL_PLUGIN constant name of "__GLOBAL_PLUGIN__". In some senses, while creating a plugin or a function, a name may not be provided and so a random name in the form of a plugin (p_<random_ascii_chars>) or function (f_<random_ascii_chars>) is used.  ### Contribution Checklist  - [X] The code builds clean without any errors or warnings - [X] The PR follows the [SK Contribution Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md) and the [pre-submission formatting script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts) raises no violations - [X] All unit tests pass, and I have added new tests where possible - [ ] I didn't break anyone 😄 --------- Co-authored-by: Evan Mattson <evan.mattson@microsoft.com>

Python: Add plugin class that can hold multiple types of functions (e.g., native and prompts) #4560

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions