lxml version bundled with Inkscape is old

The OS X packages include lxml for 4 python (intel) versions (2.3, 2.4, 2.5, 2.6) and 3 python (ppc) versions (2.3, 2.4, 2.5). It looks like 4 or more different lxml versions as well (no lxml-*.egg-info included). Do you know how I could easily verify the bundled lxml versions (as a python ignoramus ;-)?

I think it is important to agree on a min version for Python and the included modules on all platforms (there were brief discussions about python versions in bug #387946 and bug #387446).

- linux: how are the dependencies handled on linux platforms / different distributions?
- win32: package includes its own python binary (AFAIK 2.5) as well as lxml and numpy
- osx: there's a dependency to the system-installed python version, lxml and numpy are bundled

>The OS X packages include lxml for 4 python (intel) versions (2.3, 2.4, 2.5, 2.6) and 3 python (ppc) versions (2.3, 2.4, 2.5). It
> looks like 4 or more different lxml versions as well (no lxml-*.egg-info included). Do you know how I could easily verify the
> bundled lxml versions (as a python ignoramus ;-)?

I don't have access to OS X right now, so I'm not sure. System-wide, one might query from Python:
$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lxml
>>> print lxml.__path__
['/usr/lib/python2.6/dist-packages/lxml']

So in theory you could write a dummy extension that writes that info to stderr.

> I think it is important to agree on a min version for Python and the included modules on all platforms (there were brief
> discussions about python versions in bug #387946 and bug #387446).

Agreed. The win32 build should include a module that will at least be *close* to the same version as linux/OS X users. And since the win32 installer (and OSX too?) is bundling lxml, it would make sense to check the lxml version at each Inkscape release IMO.

> - linux: how are the dependencies handled on linux platforms / different distributions?

I think it's a simple flag in the package:
aptitude why python-lxml
i inkscape Recommends python-lxml

> - win32: package includes its own python binary (AFAIK 2.5) as well as lxml and numpy

Yes - 2.5

|| $ python
|| Python 2.6.2 (release26-maint, Apr 19 2009, 01:58:18)
|| [GCC 4.3.3] on linux2
|| Type "help", "copyright", "credits" or "license" for more information.
|| >>> import lxml
|| >>> print lxml.__path__
|| ['/usr/lib/python2.6/dist-packages/lxml']

| LeWitt:~ suv$ python
| Python 2.6.2 (r262:71600, Aug 23 2009, 06:02:15)
| [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
| Type "help", "copyright", "credits" or "license" for more information.
| >>> import lxml
| >>> print lxml.__path__
| ['/Volumes/blue/mp/Library/Frameworks/Python.framework/Versions/Current/lib/python2.6/site-packages/lxml']

I don't use the bundled lxml module when testing local SVN builds - above is what 'my' Inkscape r22436 would get. But 'lxml.__path__' doesn't give you the lxml version?

> So in theory you could write a dummy extension that writes that info to stderr.
You could do that - an 'sysinfo & debug' extension ;-)? Inkex.py has 'errormsg(msg)' - a dialog is more convenient with non-linux packages than system.log…

raising importance to 'medium' (doesn't cause a crash but has consequences for future extension developers). IMHO this should be discussed and solved - if possible - for Inkscape. 0.47.

| But 'lxml.__path__' doesn't give you the lxml version?

No, and I'm not sure how to get it. I was hoping that the path would at least provide a clue though.

> So in theory you could write a dummy extension that writes that info to stderr.
You could do that - an 'sysinfo & debug' extension ;-)? Inkex.py has 'errormsg(msg)' - a dialog is more convenient with non-linux packages than system.log…

Mine does not. Wait... 0.46 does not - svn does. But it just writes to stderr ;) Which does produce a dialog btw.

> svn does. But it just writes to stderr ;) Which does produce a dialog btw.
I might have been confused by the discussion in bug #169985: comment 27 and following showed different handling of stderr output - I am not sure if it was platform or inkscape version dependent: some extensions seem to drop stderr and/or use errormsg() if 'stderr' or other output needs to be seen from within Inkscape. But if all 'stderr' messages are shown in a dialog then my point is moot ;-)

Well, I'm sure that in 0.46 in both linux and win32 stderr appears in a dialog. I'm also sure that inkex.errmsg() dumps to stderr w/newlines (which is kinda funny, since I defined the same function in my extension for debugging).

If you need me to confirm this in SVN I will, but it may take some time b/c I do not have win32 set up to build anything.

just tried (using your undo_crash.py script from bug #249035 as template)
| inkex.errormsg(lxml.__path__)
which returns the path to the used module in 0.47pre3 and r22436.

> If you need me to confirm this in SVN I will
If 'this' means 'handling of python stderr in 0.47' maybe it should go to a separate report ("new extension for debugging extensions" ;-)… Let's focus here about packaging updated python modules and finding a way to ensure a minimal version that extension developers can rely on to be available out-of-the-box across all platforms.

attached a 'debug' extension that returns the version number of the used
lxml and numpy python modules. Any help to improve is appreciated.
Should run on both 0.46 (no inkex.errormsg) and 0.47pre. Adapt sys.path
as needed.

python module versions in Inkscape 0.46-2, 0.47pre3 and SVN on OS X 10.5.8

OK - here's my take on how lxml (and likewise numpy) is handled on the three arches as of right now:

linux: No check at build time. If the packager (of the binary) adds a dep/recommend, python-lxml is installed when inkscape is installed. If not, then the extensions themselves complain about missing python-lxml

win32: Simply an egg included in the bundled Python (2.5). Can find no reference to this in SVN, or any sort of automated set-up within the win32 source 7zip.

OS X: Many versions copied over at build time: see line 280 of inkcape/packaging/macosx/osx-app.sh

I'm a little unclear on where the win32 version comes from - but I do not have much experience at building on Windows. AFAICT, there must be another step between SVN and the Win32 source.

> I'm a little unclear on where the win32 version comes from - but I do
> not have much experience at building on Windows. AFAICT, there must be
> another step between SVN and the Win32 source.

Maybe be part of the devlibs:

Win32Port - Inkscape Wiki: Download The MinGW Compiler & Dev Libraries
<http://wiki.inkscape.org/wiki/index.php/Win32Port#Download_The_MinGW_Compiler_.26_Dev_Libraries>

Yes - that's it (the devlibs package). I tried making a patch, but don't really know all of the ins and outs of SVN. If it were a matter of editing files and making a patch, it would be no problem but replacing files seems to be trickier.

Will keep poking at it, but perhaps we can bug Ishmal to update lxml/numpy in the dev libs?

> Will keep poking at it, but perhaps we can bug Ishmal to update
> lxml/numpy in the dev libs?

corresponding thread in the inkscape-devel list:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31788>

btw - 0.47pre4 (src) has just been uploaded to sf.net...

I agree with Ted's assessment (comment #4) in the thread. This is really just a packaging issue, and the only real problem that I see will be for anyone writing new extensions on platform A, only to discover that they do not work on platform B or C.

Linux: Inkscape will generally have access to an up-to-date version of lxml available - so I see nothing to do there.

Win32: the maintainer of the devlibs will need to periodically update/replace the bundled modules. I've discovered that svn will allow a pull in from an external source (eg: lxml's svn repo), but that might cause breakage in the future - it would certainly have to be tested with each release, and probably not worth it.

OSX: at build time, one must add the newer modules and use the '-py' flag when compiling (see http://inkscape.modevia.com/macosx-snap)

I'm not sure I'm learned enough in SVN to get Win32 taken care of, but I suppose if I created a new branch for testing it would be pretty hard to mess things up :)

> I agree with Ted's assessment (comment #4) in the thread. This is
> really just a packaging issue, and the only real problem that I see will
> be for anyone writing new extensions on platform A, only to discover
> that they do not work on platform B or C.

that was my point I apparently failed to communicate ;-)

Packaging needs coordination and extension developers need an up-to-date
resource that informs about the status of the default installations on
platforms for which Inkscape.org provides packages on sf.net. From there
it's the developer's decision whether he accommodates to the common
minimum versions or provides installation instructions where needed.

For me it's unclear how to address packaging coordination. I know Chris
Morgan has provided the recent win32 builds and Micheal Wybrow updates
the osx packages. These processes seem independent - yet they would need
to figure out if common minimum module versions for all supported os and
python versions exists.

The Wiki Extensions category
<http://wiki.inkscape.org/wiki/index.php/Category:Extensions>
and Extension repository
<http://wiki.inkscape.org/wiki/index.php/Extension_repository>
could provide an updated extension central for developers.

related reports about the dependencies of python modules:
Bug #168843: “Modify path->perspective is broken”
Bug #174992: “perspective.py requires dependency on python-numpy”
Bug #178022: “python extensions fail on win32”

and the python UniConvertor bundled on win 32 needs an upgrade as well:
Bug #442010: “import corel draw files does not work properly on windows”:

another related report: bundled UniConvertor 1.1.3 on win32 doesn't support PLT output
Bug #501154: “Save as.. fails for many formats on Vista PC”

Why moving this report completely out of the Inkscape bug tracker? IMHO this concerns the osx port as well because it ships with the python modules lxml and numpy included.

This is something new to me. But the OSX lxml is neither in the devlibs nor in the Inkscape tree. Maybe the bundled libraries should be stored in another Launchpad project?

Krzysztof Kosinski wrote on 2010-05-30:
> OSX lxml is neither in the devlibs nor in the Inkscape tree

The bundled python modules are referenced in the build/packaging scripts for osx which are part of the Inkscape source tree. Currently the archive with the python modules itself is hosted at the modevia site.