GIMP PyDev
github.com
GIMP PyDev
1–10 of 33 posts
Re: GIMP PyDev
#2This 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.
Re: GIMP PyDev
#3This 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.
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.
Re: GIMP PyDev
#4This 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.
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.
Re: GIMP PyDev
#5This 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.
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.
Re: GIMP PyDev
#6This 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.
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 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...
Re: GIMP PyDev
#7This 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.
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.
Re: GIMP PyDev
#8This 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.
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 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
Re: GIMP PyDev
#9Earlier quoted context omitted.
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 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…
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.
Re: GIMP PyDev
#10This 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.
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.