Hacker News Reader

Comment by toyg | Hacker News Reader

This approach of using the system python, although somewhat mitigated by flatpak, is Bad. What happens when you have to ship GIMP on non-flatpak platforms, like MacOS...? You're either stuck on an ancient version or you must ask the user to install it separately. Neither option is particularly good.

It shouldn't be too hard to pack up a python executable instead.

View on HN

Sorry, but what prevents a different approach on each platform?

It's fairly common to ship Windows applications with bundled DLLs but to link to more system libraries on Linux platforms, for instance.

QGIS on Linux does this as well, and it's really quite annoying. On Windows nobody assumes you'll have python installed, so everybody ships their own python. Sure I probably have at least 6 pythons installed on my machine, but at least I know that I can safely upgrade or install a package in one python without it risking breaking 6 other applications.

I think part of that has to do with it being a pythonic choice as well though. Python actively encourages you to segment off your environment for everything you do, that mentality continues to packaging and deploying.

Gimp's use of Flatpack has greatly simplified staying up to date for Linux users.

The Gimp community is not obligated to dedicate resources to working around Apple's business decisions. The absence of Flatpack on MacOS is solely for the sake of Apple's bottom line.

Apple itself certainly has the wherewithal to make Gimp available on its platforms. It simply does not have the interest. As you say, it shouldn't be too hard.

That’s as unreasonable as expecting every OS under the sun should ship apt-get, and it’s really not what this is about. I’m not criticising GIMP’s adoption of flatpak, I’m pointing out that building its essential infrastructure around a specific deployment scenario is probably not in GIMP’s best interest.

In what way is not in the developers' best interest?

They are volunteers.

I don't even understand what the standalone Python interpreter is used for; for plug-ins wouldn't you expect the hosting application to integrate the interpreter? That's at least my "traditional" view of how application plug-ins work.

On the other hand it's 20 years since I last worked with GIMP plug-ins, and back then it was C all the way.

GIMP always supported their Scheme dialect.

GIMP plugins run in a separate process from the main process. My guess is that the main motivation is resiliency, to prevent crashes in buggy plugins from taking down the whole program. The plugin is essentially a standalone program that loads a library to help it talk to the parent process, in the case of both C and Python, so there isn't a real need to embed the Python interpreter in another process like you would with a more "traditional" Python plugin architecture.

https://wiki.gimp.org/wiki/Hacking:Plugins#GIMP_Plug-in_Arch...

Thanks, that makes sense of course and I'm pretty sure me[-20 years] knew this but it has since been flushed out of the poor brain tissue.

Gimp has had python plugins for more than 20 years, so it probably hasn't changed since you worked with them before: https://www.gimp.org/docs/python/index.html

Reply on news.ycombinator.com