inkex.py cannot find lxml

Asked by Zach Smith on 2009-03-23

With the OS X binary I downloaded (0.46) I get this error whenever I try to use something from the effects menu:

The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore this extension. Please download and install the latest version from <http://cheeseshop.python.org/pypi/lxml/>, or install it through your package manager by a command like: sudo apt-get install python-lxml

I believe that I have libxml2 and the lxml wrapper installed, i.e. when I installed inkscape from fink (0.46), the effects work. Also, if I run python from a command line and type 'from lxml import etree', which is where the scripts seem to be erring, I get no error.

The OS X version blends a bit better with the interface. Any idea of how I can tell the OS X app where lxml is.

Zach

Question information

Language:
English Edit question
Status:
Solved
For:
Inkscape Edit question
Assignee:
No assignee Edit question
Solved by:
su_v
Solved:
2009-07-22
Last query:
2009-07-22
Last reply:
2009-07-04
mahfiaz (mahfiaz) said : #1

You could see if in 0.46 .dmg file there is lxml file. If yes, copy it over to the new one.

kPrussing (kprussing74) said : #2

I am also having this problem on windows xp. I tried this solution, but it is still not working. Any other suggestions?

Zach Smith (zvsmith) said : #3

Perhaps I should say that I don't know what mahfiaz is suggesting. There is an lxml library included in the .dmg file. I am not sure where he would have me copy it. On top of my version that seems to be working? Into a package managed directory? Or should I copy my library that seems to be working into the native OS X one, i.e. into a place where that the applications seems to be unable to locate?

This was not a critical problem so I let it pass, but it didn't solve my problem, so that is why this is still open. We are nearing the 0.47 release and I am hoping it will be fixed either directly or as a side effect of the developers' hard work.

kPrussing:
My take here is that applications are executed in some kind of environment. In a Unix like environment this means environment variables. If the Windows version of Inkscape is running under Cygwin, then it seems that you will need make sure it has the correct environment. I do this by executing inkscape from a shell where the proper environment is defined and the process inherits these variables. I think the proper OS X way is to play around with Info.plist, but everything I have tried along these lines has failed.

More to the point, I believe that the variable that is important here is PYTHONPATH. This is a colon separated list of directories that Python searches for libraries. If the path to the LXML wrapper is not there, I imagine python will fail on the import command and you will get this error.

Assuming you actually do have the python lxml library installed, one thing I suggest you try (if you have Cygwin installed) is to run it from a bash shell where you know PYTHONPATH has an appropriate value.

You also might be able to troubleshoot this a bit more if you create an extension that just prints the environment that it is running in to a file. I assume that a process that Inkscape launches will have the same environment as itself.

Best su_v (suv-lp) said : #4

Hi Zach!
Best way would be to try a recent development snapshot from <http://inkscape.modevia.com/macosx-snap/?C=M;O=D> or the the latest 0.47 prerelease from <http://sourceforge.net/projects/inkscape/files/> to test if your problem persists. I think both are reasonably stable (though all caveats regarding the use of beta versions in productive environments apply ;-). If you still have difficulties with (only some? that's odd) effects or now called extensions please file a bug report to make the issue known to the developers before the release of 0.47. Don't forget to read the Release notes for 0.47 first <http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47>!

Yet, here my take on your problem: mixing fink/macports installations with default osx frameworks and downloaded bundles sometimes can create trouble when different versions (e.g. Perl, Python) coexist in separate installs.

Inkscape.app tries hard to preempt as many issues as possible, within the nature of osx application bundles:
AFAIU app bundles are primarily self-contained (all extra frameworks, libraries and resources they need are within the bundle), and rely on the default frameworks and paths of OS X (as installed by apple) to find necessary shared resources and libraries.

So, assuming you downloaded the latest Inkscape 0.46-2 from inkscape.org: all necessary extra python libs are included in the bundle. Python effects should work 'out of the box'.

The inkscape binary is launched through a series of bash shell scripts, which prepare and set the environment for GTK+, Python, inkscape itself etc.

If you need to customize $PYTHONPATH on your system, open the Inkscape.app package and navigate to 'Contents/Resources/bin'. Open the file 'inkscape' with TextEdit (do not double click but use the context menu). This shell script finally calls 'inkscape-bin' after setting the environment. Change $PYTHONPATH
on line 28 to your needs, save, restart Inkscape.

There are several bug reports (many marked 'Fix released') about issues with Python, this one <https://bugs.launchpad.net/inkscape/+bug/168440> for example has some comments from JiHO that might give you more insight if interested. Beware though that current development versions have changed, so some issues are solved, others maybe persists.

On a last note: old questions in the answers.launchpad section do not 'resurface' when a new comment is added: they might have expired due to inactivity and are not automatically displayed or included in the search results.

hth, ~suv

su_v (suv-lp) said : #5

oops, sorry, that link got mangled:
Release Notes for Inkscape 0.47: http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47

su_v (suv-lp) said : #6

Followup to my first comment (sorry, I now see I didn't read your descriptions carefully enough - it was too late at night ;-) regarding your Info.plist quest - a general way to define a shell environment that is inherited by every application managed by launchd (basically every app you start by (double)clicking its icon) is the use of ~/.MacOSX/environment.plist.

additional links from the 'Apple Developer Connection' site:
Runtime Configuration Guidelines: Environment Variables
<http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html#//apple_ref/doc/uid/20002093-BCIJIJBH>
Technical Q&A QA1067: Setting environment variables for user processes
<http://developer.apple.com/qa/qa2001/qa1067.html>
Mac OS X Technology Overview: Command Line Primer: Environment Variables
<http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology_Overview/CommandLine/CommandLine.html#//apple_ref/doc/uid/TP40001067-CH271-SW10>

IMHO one reason why it's seldomly used or recommended lies in its static character e.g. you cannot append to existing (system wide defined) variables (like $PATH) but are limited to setting absolute values at login time thus risking to override system defaults or missing links to updated or newly installed versions. Keeping '~/.MacOSX/environment.plist' in sync with the various shell startup files (.profile, .bash_profile, .bashrc etc.) alone seems a hassle and prone to mistakes. To quote from ADC "The answer to your next question is: Yes, this is a relic left over from OpenStep/NextStep."

I'd be interested in any kind of feedback - especially if and how you got the python effects running?
hth, ~suv

Zach Smith (zvsmith) said : #7

I haven't tried much of suv's suggestions but we finally have an OS X Tiger build of 0.47pre1 and the problem was fixed. Thanks, suv, for all of the info about the OS X execution environment.

Zach Smith (zvsmith) said : #8

Thanks ~suv, that solved my question.