https://cwiki.apache.org/confluence/display/FLINK/FLIP-552+Support+ML_PREDICT+for+Python+based+model+providers
On Mon, Oct 13, 2025 at 4:10 PM Őrhidi Mátyás <[email protected]> wrote: > > Swapna, I can help you to create a FLIP page. > > On Mon, Oct 13, 2025 at 3:58 PM Hao Li <[email protected]> wrote: > > > > 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 > > > >
