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.
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.
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 :)