Python dependencies for extensions on all platforms need common min versions
While the topic raised in the versioning scheme thread mentions a general API version possibly separated from the program version, bug #448285 "lxml version bundled with Inkscape is old" https://bugs.edge.launchpad.net/inkscape/+bug/448285 brings up an issue that could be discussed and solved for 0.47 (especially as 0.47pre4 has just been branched).
Could there be a central document on Inkscape.org available for all future extension developers (and package maintainers) that defines the python version and necessary python modules for the current release and lists the minimal versions every Inkscape installation needs to provide for the extension-system out-of-the-box? Or could this be handled entirely by the configure and packaging scripts, which then create an updated 'README.python' document included in the 'share/extensions'?
~suv
2009/10/11 ~suv <suv-sf@...58...>:
Or could this be handled entirely by the configure and packaging scripts, which then create an updated 'README.python' document included in the 'share/extensions'?
That's definitely not a good idea because globally you'd get thousands of versions of this README file, each one listing different versions, which would create no end of confusion. There's already some dependency checking functionality in the module system that lets you specify that some extension requires an external executable, and if the dependencies are not met the extension is disabled at runtime. I think we should extend that to allow INX files to specify Python dependencies.
Regards, Krzysztof
On 11/10/09 12:48, Krzysztof Kosiński wrote:
2009/10/11 ~suv <suv-sf@...58...>:
Or could this be handled entirely by the configure and packaging scripts, which then create an updated 'README.python' document included in the 'share/extensions'?
That's definitely not a good idea because globally you'd get thousands of versions of this README file, each one listing different versions, which would create no end of confusion. There's already some dependency checking functionality in the module system that lets you specify that some extension requires an external executable, and if the dependencies are not met the extension is disabled at runtime. I think we should extend that to allow INX files to specify Python dependencies.
Sorry if my brief description of bug #448285 was unclear: it's about the bundled python _modules_ - they cannot be checked as dependency (not in path, no executable) nor exists a reference which versions are bundled with 0.46 and upcoming 0.47. This is an issue mainly on Windows and OS X platforms, because the python modules (and on win32 the python binary itself) are included in the prebuilt packages. However - if an extension developer wants his extension to be used on all platforms he must rely on an agreed min version of python and the two basic modules lxml and numpy, be it on win32 or linux or osx. I think the current dependency check is rather late in the process from a users point-of-view; asking him to update the bundled python-modules in an osx application package to run a specific extension is unrealistic IMHO.
The bug was filed because in the 0.47pre3 packages an apparently rather old version of lxml is included: on Windows v1.3b 2007, on OS X v1.3.6 (for Python 2.5), current version however is v2.2.2.
~suv
On Sun, 2009-10-11 at 15:36 +0200, ~suv wrote:
This is an issue mainly on Windows and OS X platforms, because the python modules (and on win32 the python binary itself) are included in the prebuilt packages.
Honestly, since it is only a Windows and OSX problem, it seems like it's something that'll change with the packaging. There is no reason that the packaging can't update while the Inkscape version remains constant. So any solution that we'd give, probably wouldn't have much weight.
I'm not against checking python versions, but it seems like a lot for Inkscape to do on it's own. That seems like a distribution problem to me whether it is a Linux distributor or the Windows package.
--Ted
Hi there, just joined the list.
Ted Gould <ted@...360...> writes:
On Sun, 2009-10-11 at 15:36 +0200, ~suv wrote:
This is an issue mainly on Windows and OS X platforms, because the python modules (and on win32 the python binary itself) are included in the prebuilt packages.
Honestly, since it is only a Windows and OSX problem, it seems like it's something that'll change with the packaging. There is no reason that the packaging can't update while the Inkscape version remains constant. So any solution that we'd give, probably wouldn't have much weight.
Agreed, but IMO Inkscape (the project) should *try* to ship modules of the same relative age across all platforms. After digging into this issue a bit, it looks as though this is just going to be a matter of bugging the folks who maintain the OS X and win32 builds to upgrade now and then.
I'm not against checking python versions, but it seems like a lot for Inkscape to do on it's own. That seems like a distribution problem to me whether it is a Linux distributor or the Windows package.
+1 - no need for Inkscape (the program) to check the deps.
Linux is easy - the packager just recommends or requires python-lxml and python-numpy and the distro versions are pulled in at install time. But because the win32 (and OS X?) installer bundles the two modules it's up to the packager to stay on top of them. And (again IMO) it does not seem unreasonable to ask the packagers to upgrade now and then to keep things (roughly) in sync across all platforms. It's quite likely that they have just been forgotten about since the built-in modules still work with the older modules.
The 2.x version of lxml exposes new functions. So an extension written on linux may not work on windows without upgrading the bundled lxml module or rewriting the extension - which is not going to deter me, but is not very friendly. Hence the bug, and the hope that the win32/OS X installers for 0.47 will ship newer modules.
Anyway - I'm looking forward to helping out where I can. I've been using Inkscape for years (love it!), and now I'm writing an extension for a client (which will become public). After that I'd like to help out with other extension-specific tasks. The proposed extension repository looks like a good fit for me, as I'm no whiz at c/c++ but know python/web stuff pretty well.
Chris
On Mon, 2009-10-12 at 01:14 +0000, Chris Mohler wrote:
Anyway - I'm looking forward to helping out where I can. I've been using Inkscape for years (love it!), and now I'm writing an extension for a client (which will become public). After that I'd like to help out with other extension-specific tasks. The proposed extension repository looks like a good fit for me, as I'm no whiz at c/c++ but know python/web stuff pretty well.
Cool, great to have you. We're trying to finish up a release right now, but I'm excited about making extensions that we don't include more of a possibility in future releases.
--Ted
participants (4)
-
Chris Mohler -
Krzysztof Kosiński -
Ted Gould -
~suv