Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wire up plugin interface #353

Merged
merged 3 commits into from
Jun 5, 2024
Merged

Wire up plugin interface #353

merged 3 commits into from
Jun 5, 2024

Conversation

jhamon
Copy link
Collaborator

@jhamon jhamon commented Jun 5, 2024

Problem

We need a way to develop, test, demo, version and release features when they are in a preview or pre-release state independent from the stable core sdk. New features should only enter the sdk core when rapid refinement and iteration has tapered off and we're ready to stabilize the feature. This will help us innovate and ship faster.

Solution

We have implemented a plugin interface that allows us to extend the Pinecone class with experimental features defined elsewhere. For now, this plugin interface is only intended for internal use at Pinecone.

There are three pieces involved here: the changes in this diff, a small separate package called pinecone_plugin_interface, and the plugin implementations themself. Currently, there are no publicly available plugins.

The Pinecone class here imports a load_and_install function from the pinecone_plugin_interface package. When invoked, this function scans the user's environment looking for packages that have been implemented within a namespace package called pinecone_plugins. If it finds any, it will use the client_builder function supplied by the Pinecone class to pass user configuration into the plugin for consistent handling of configurations such as api keys, proxy settings, etc.

Although the amount of code involved in pinecone_plugin_interface is quite meager, externalizing it should give some flexibility to share code between the sdk and plugin implementations without creating a circular dependency should we ever wish to include a plugin as a dependency of the sdk (after functionality has stabilized).

I have been defensive here by wrapping the plugin installation in a try/catch. I want to be confident that the mere presence of an invalid or broken plugin cannot break the rest of the sdk.

Type of Change

  • New feature (non-breaking change which adds functionality)

Test Plan

Tests should be green. I added some unit tests covering the new builder function stuff. As far as integration testing, I can't really add those here until we have publicly available plugins. But I've done manual testing to gain confidence.

@jhamon jhamon marked this pull request as ready for review June 5, 2024 02:32
Copy link
Contributor

@austin-denoble austin-denoble left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work, Jen. I need to spend more time getting familiar with the https://github.com/pinecone-io/python-plugin-interface package, but the changes to the client surface are really straightforward.

Comment on lines +9 to +10
# different copies of the ModelNormal class. Therefore cannot be used interchangeably.
# without breaking the generated client code anywhere it is relying on isinstance to make
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super nit: I think there's an extra period after interchangeably. Thank you for these detailed comments also, helpful for putting the pieces together.

@jhamon jhamon merged commit 701f6b6 into main Jun 5, 2024
81 checks passed
@jhamon jhamon deleted the jhamon/plugin-interface branch June 5, 2024 17:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants