fix(py): Removing circular dependencies on Genkit in Plugin API

[kirgrim]

Description:

• unchained registry from veneer, making it standalone class container
• removed Genkit Veneer references from Plugin API
• moved implementation of registering model to Registry

Checklist (if applicable):

• PR title is following https://www.conventionalcommits.org/en/v1.0.0/
• Tested (manually, unit tested, etc.)
• Docs updated (updated docs or a docs bug required)

[Irillit]

Here I'm thinking about implementing the initialization here, but leaving _register_model() empty. I would create abstract methods for:

• register_models()
• register_indexers()
• register_retrievers()
• register_embedders()

and etc

[Irillit]

Let me try to create the PR with how I see it as well.

[kirgrim]

Here I'm thinking about implementing the initialization here, but leaving _register_model() empty. I would create abstract methods for:

• register_models()
• register_indexers()
• register_retrievers()
• register_embedders()

and etc

Idea of making register_model singular is in abstracting a logic of registry attachment. We attach to registry per each model, thus it is still required. But it may make sense to define register_models, although i am afraid not every plugin has multiple models

[yesudeep]

What is the rationale behind using a classmethod here?

Each Genkit instance composes its own registry instance no?

[kirgrim]

What is the rationale behind using a classmethod here?

Each Genkit instance composes its own registry instance no?

no, it is defined on the class-level

[Irillit]

And should we have more than one Genkit class?

[kirgrim]

And should we have more than one Genkit class?

makes no sense - polymorphic behaviour will be granted by the plugins api

[kirgrim]

@pavelgj please take a look, it seems like we may remove this circular dependency as there is single registry per class. Is it intended/allowed/makes sense to have multiple instances of Genkit veneer instantiated during the runtime?