Hi Swapna, Thanks for the proposal. Can you put it in a FLIP and start a discussion thread for it?
>From an initial look, I'm a bit confused if this is a concrete implementation for "generic-python" or it's generic framework to handle python predict function. Because everything seems concrete like `GenericPythonModelProviderFactory`, `GenericPythonModelProvider` exception the final Python predict function. Also if `GenericPythonModelProviderFactory` is predefined, do you predefine the required and optional options for it? Will it be inflexible if predefined? Thanks, Hao On Mon, Oct 13, 2025 at 10:04 AM Swapna Marru <[email protected]> wrote: > > Hi ShengKai, > > Documented the initial proposal here , > > https://docs.google.com/document/d/1YzBxLUPvluaZIvR0S3ktc5Be1FF4bNeTsXB9ILfgyWY/edit?usp=sharing > > Please review and let me know your thoughts. > > -Thanks, > Swapna > > On Tue, Sep 23, 2025 at 10:39 PM Shengkai Fang <[email protected]> wrote: > > > I see your point, and I agree that your proposal is feasible. However, > > there is one limitation to consider: the current loading mechanism first > > discovers all available factories on the classpath and then filters them > > based on the user-specified identifiers. > > > > In most practical scenarios, we would likely have only one generic factory > > (e.g., a GenericPythonModelFactory) present in the classpath. This means > > the framework would be able to load either PyTorch or TensorFlow > > models—whichever is defined within that single generic implementation—but > > not both simultaneously unless additional mechanisms are introduced. > > > > This doesn't block the proposal, but it’s something worth noting as we > > design the extensibility model. We may want to explore ways to support > > multiple user-defined providers more seamlessly in the future. > > > > Best, > > Shengkai > >
