Support per-plugin Python interpreter override

[O-possum]

Is your feature request related to a problem? Please describe.

Python dependency management isn't great. If two plugins have incompatible dependencies, they cannot use the same interpreter. Relying on one interpreter for all plugins also necessitates an agreed-upon standard Python version for all plugins to use in order to maximize compatibility. When that Python version reaches end-of-life, that also means that the community will have to agree to transition or continue to use a version of Python that is no longer supported.

Describe the solution you'd like

On top of the "base" Python interpreter (used by all plugins by default), it should also be possible to configure a separate interpreter to be used by each plugin.

This feature is not intended to allow plugin developers to just use whatever Python version they want and be obtusely strict with dependency version specifications. The primary purpose of this change would be to open the door to using modern Python tooling (such as https://github.com/astral-sh/uv) for installing/launching plugins while immediately presenting a workaround for plugins with incompatible dependencies.

Migrating to a tool like uv down the line would remedy the issue of requiring an agreed-upon Python version for plugins, hand off the responsibility of dependency installation to uv rather than the plugin installer, and give each plugin its own isolated known-good Python environment.

While the purpose of this issue isn't to integrate with such a tool, allowing separate interpreters per plugin would be a good first step towards that architecturally while also presenting some immediate value.

Describe alternatives you've considered

• A separate Python venv could be used for troublesome plugins, but having to reconfigure your interpreter each time you want to use the plugin negates the convenience of a launcher.
• An interpreter switcher plugin could be made (might already exist?) that would allow you to perform the above more quickly, but that's another thing to remember before you can use the troublesome plugin.

[WhitespaceQ]

Read the title and immediately think "oh uv will solves this issue" but as of now we're just going back to NodeJS bloat

I think it is completely OK for the maintainer to specify/enforce a third-party dependency/version lock on their environment and all plugins developers should adhere to that, letting each plugins to bring their own .venv via uv will increase install time/download sizes and complexity

When all you have is a hammer, everything looks like a nail.

[cibere]

Although I agree that the current system isn't great, you seem to misunderstand something.

Python plugins are not supposed to install dependencies. In fact, the version of python that flow downloads doesn't even have pip. Python plugins are supposed to download all of their dependencies into a lib folder during their packaging/publishing workflow, which gets added to path when the plugin is run.

[O-possum]

Python plugins are not supposed to install dependencies.

Ah, apologies, it's been a while (just a couple years haha) since I've messed with writing plugins so I'm definitely rusty with how they're packaged.

As for @WhitespaceQ 's comment, I definitely agree uv isn't quite the perfect solution, but I could see how something like it could allow for increased interoperability down the line. That said, I do believe it would be much lower overhead than traditional venv due to the fact that uv caches and symlinks dependencies by default rather than reinstalling them every time.

Whatever the case, I think adding this specific feature would be a step in the right direction towards increasing portability.

[deefrawley]

1. There shouldn't be "troublesome" plugins. If the plugin has issues then the author should fix them or the Flow team should be petitioned to remove the plugin from the store.
2. Security. Having dependency managed in the github workflow ensures we can inspect plugins at the source and each plugin gets a verbose copy of its libraries locally within the Flow config directory for inspection/troubleshooting if needed. For the majority of users Flow plugins have a known good python environment - the interpreter that comes with Flow and the libraries bundled with the plugins. Modern tooling isn't needed so Flow can manage this.