Re: [Inkscape-devel] Advice on how to update lxml on OS X
On Mon, Oct 19, 2009 at 11:21 PM, ~suv <suv-sf@...58...> wrote:
Just tested and put the lxml and numpy for python 2.5 that I had compiled with MacPorts into the 0.47pre4 bundle and Inkscape loads them fine and reports lxml version 2.2.2 :)
i.e. I could zip them up and add the zip to your bug report for you or him to download _if_ your client runs 10.5.8 (i386) with python 2.5 or python 2.6 installed. He just has to unzip them and copy the folders into the bundle, no need to build them on his machine. If he still uses Tiger OS X 10.4.x or has a PPC processor then I can't help.
I haven't built a DMG before - so I would prefer a simple zip...
Back on list - just for posterity :)
That is good news - I'm still waiting to hear back on his OS X version and arch. I'll report back once I have some more info either way.
Thanks for the assistance. Chris
On 20/10/09 06:33, Chris Mohler wrote:
On Mon, Oct 19, 2009 at 11:21 PM, ~suv <suv-sf@...58...> wrote:
Just tested and put the lxml and numpy for python 2.5 that I had compiled with MacPorts into the 0.47pre4 bundle and Inkscape loads them fine and reports lxml version 2.2.2 :)
i.e. I could zip them up and add the zip to your bug report for you or him to download _if_ your client runs 10.5.8 (i386) with python 2.5 or python 2.6 installed. He just has to unzip them and copy the folders into the bundle, no need to build them on his machine. If he still uses Tiger OS X 10.4.x or has a PPC processor then I can't help.
I haven't built a DMG before - so I would prefer a simple zip...
Back on list - just for posterity :)
That is good news - I'm still waiting to hear back on his OS X version and arch. I'll report back once I have some more info either way.
Arrgh - I was too fast to respond or too sloppy in testing! Obviously the path to the python installation (inside the MacPorts tree) is hardcoded into the modules - if I rename the installation directory (I have not used the default prefix '/opt/local') the python extension fail with the ominous 'fantastic lxml wrapper for libxml' story :(
Will try again tomorrow, but might need some help as well on how to create 'portable' python module packages...
sorry, ~suv
On 20/10/2009, at 12:13 AM, ~suv wrote:
Arrgh - I was too fast to respond or too sloppy in testing! Obviously the path to the python installation (inside the MacPorts tree) is hardcoded into the modules - if I rename the installation directory (I have not used the default prefix '/opt/local') the python extension fail with the ominous 'fantastic lxml wrapper for libxml' story :(
Will try again tomorrow, but might need some help as well on how to create 'portable' python module packages...
I'm not sure how the original ones were created to be portable (I think JiHO built them). They certainly don't look portable since some link to dylibs in /opt/local. I may have broken them in that respect when I removed the DYLD_LIBRARY_PATH variable, though they appear to work on Leopard installations fine. This might be something to do with the different versions and architectures being linked to different libraries. That is, the ones I have tested on Leopard might only be linked to the system libraries and work, but the others to non- present Macports libraries.
I have a patch (attached) for the packaging script that does the path rewriting on the python files, but I'm not convinced it works completely since I was testing it on SnowLeopard and still couldn't get the extensions to run, as per my last email in the other thread. Anyway, that's as far as I got last time I had a chance to look at the problem.
Cheers, Michael
On 20/10/09 09:25, Michael Wybrow wrote:
On 20/10/2009, at 12:13 AM, ~suv wrote:
Arrgh - I was too fast to respond or too sloppy in testing! Obviously the path to the python installation (inside the MacPorts tree) is hardcoded into the modules - if I rename the installation directory (I have not used the default prefix '/opt/local') the python extension fail with the ominous 'fantastic lxml wrapper for libxml' story :(
Will try again tomorrow, but might need some help as well on how to create 'portable' python module packages...
I'm not sure how the original ones were created to be portable (I think JiHO built them). They certainly don't look portable since some link to dylibs in /opt/local. I may have broken them in that respect when I removed the DYLD_LIBRARY_PATH variable, though they appear to work on Leopard installations fine. This might be something to do with the different versions and architectures being linked to different libraries. That is, the ones I have tested on Leopard might only be linked to the system libraries and work, but the others to non-present Macports libraries.
One cause on 10.5.8 is the missing DYLD_LIBRARY_PATH variable in the packages from sf.net!
Locally for testing I don't use the install_path rewriting (my MacPorts $PREFIX is too short and I can't re-install and upgrade to MacPorts 1.8.1 due to a bug still unfixed... waiting for 1.8.2 ;-).
So I tested with a default application bundle built from SVN, (using the original launcher script with its default $PATH settings and 'export DYLD_LIBRARY_PATH="$TOP/lib"') and replaced the Python site-packages for i386 and python 2.5/2.6 (included from the DMG on modevia) with newer modules copied from the MacPorts tree.
Before launching this app I renamed the MacPorts tree so that any install_path reference would break. Inkscape-SVN.app nevertheless loads the new modules without error and reports the new lxml version (2.2.2) - using the apple-supplied python v2.5.1.
I have a patch (attached) for the packaging script that does the path rewriting on the python files, but I'm not convinced it works completely since I was testing it on SnowLeopard and still couldn't get the extensions to run, as per my last email in the other thread. Anyway, that's as far as I got last time I had a chance to look at the problem.
I will try if I can apply the 'fixlib' function to the new python modules manually and report back if I can get it to run with Inkscape-SVN.app on 10.5.8.
~suv
[ addendum ]
On 20/10/09 15:51, ~suv wrote:
Locally for testing I don't use the install_path rewriting (my MacPorts $PREFIX is too short and I can't re-install and upgrade to MacPorts 1.8.1 due to a bug still unfixed... waiting for 1.8.2 ;-).
My current MacPorts prefix is '/Volumes/blue/mp'. '/opt/local' doesn't exist on my system.
I will try if I can apply the 'fixlib' function to the new python modules manually and report back if I can get it to run with Inkscape-SVN.app on 10.5.8.
I meant 'if I can get the updated python modules to run with Inkscape 0.47pre4 from sf.net on 10.5.8.'
~suv
OK - He's on 10.5.7 and i386 (whew), and I'm going to walk him through Macports. I used Macports myself some years ago, so I think it will go pretty smoothly.
But a semi-related follow-up: where should user extensions go in OS X? Does a ~/.inkscape get created?
Thanks, Chris
On 21/10/09 02:33, Chris Mohler wrote:
But a semi-related follow-up: where should user extensions go in OS X? Does a ~/.inkscape get created?
I keep them in '~/.config/inkscape/extensions' (0.47pre). There was a bug that the subdirectories in '~/.config/inkscape' were not automatically created, but this was recently fixed in rev.22349. [Bug #437938] “User resource directories no longer created if they do not exist” https://bugs.launchpad.net/inkscape/+bug/437938
If he is using Inkscape 0.46, put them into '~/.inkscape/extensions'. But AFAIK then your own extension script needs to append the path to the bundled extensions so that modules like inkex.py are found... (this is not necessary with Inkscape 0.47).
# only needed if you don't put the script into the installation directory import sys sys.path.append('/usr/share/inkscape/extensions') # OS X sys.path.append('/Applications/Inkscape.app/Contents/Resources/extensions') # win32 ??? #sys.path.append('C:\Program Files\Inkscape\share\extensions')
~suv
On Tue, Oct 20, 2009 at 7:53 PM, ~suv <suv-sf@...58...> wrote:
On 21/10/09 02:33, Chris Mohler wrote:
But a semi-related follow-up: where should user extensions go in OS X? Does a ~/.inkscape get created?
If he is using Inkscape 0.46, put them into '~/.inkscape/extensions'. But AFAIK then your own extension script needs to append the path to the bundled extensions so that modules like inkex.py are found... (this is not necessary with Inkscape 0.47).
Thanks.
Any tips for the non-power user on accessing the .dotfiles? I gave him a couple of commands in the terminal, but if there's a Finder shortcut or something that would probably help. I get the feeling that he's not familiar with the terminal at all, so I'm trying to go easy on him ;)
Thanks again, Chris
On 21/10/09 03:02, Chris Mohler wrote:
Any tips for the non-power user on accessing the .dotfiles? I gave him a couple of commands in the terminal, but if there's a Finder shortcut or something that would probably help. I get the feeling that he's not familiar with the terminal at all, so I'm trying to go easy on him ;)
dotfiles are hard, dot-folders are easier ;-)
to access the Inkscape preferences:
1) open a finder window 2) use menu bar 'Go > Go to Folder...' 3) enter the path to the dot-directory: '~/.config/inkscape', 4) click 'Go' -> you get a list with user preferences and all user folders like extensions, keys, palettes and templates. 5) optional: if he needs to go there often, change the view to 'as Columns' and pull the dot-folder into the left sidebar under places. 6) Tip: you can call 'Go to Folder...' from every save/open dialog using it's keyboard shortcut 'Shift+Cmd+G'
Which dotfiles does he need to access?
There are text editors that have options to show hidden files in the open/save dialog (MacVim does, though that's not one I'd recommend ;-)
Smultron has 'Open Hidden...' in the 'File' menu, a small text editor - though I just noticed that it's no longer developed: http://smultron.sourceforge.net/ (you can still download the last version 3.5.1 from sf.net).
I don't use others myself, but 'TextWrangler' (free, but not FOSS) could have similar options http://www.barebones.com/products/TextWrangler/. 'BBEdit' and 'TextMate' are the bigger ones among Mac text editors for programmers.
~suv
On 21/10/09 08:45, Chris Mohler wrote:
Aha - thanks for the tip, as it is just ~/.inkscape that I need to point him to.
That means he's using Inkscape 0.46...
I tried to copy&paste the new lxml and numpy modules into the Inkscape 0.46-2 package, but it didn't work. Let's hope that you don't get
| Bug #321346 “Bundled lxml lib not being found” | https://bugs.launchpad.net/inkscape/+bug/321346
when using python modules built with newer shared libraries in MacPorts.
~suv
I'm not sure how the original ones were created to be portable (I think JiHO built them). They certainly don't look portable since some link to dylibs in /opt/local. I may have broken them in that respect when I removed the DYLD_LIBRARY_PATH variable, though they appear to work on Leopard installations fine.[...]
One cause on 10.5.8 is the missing DYLD_LIBRARY_PATH variable in the packages from sf.net!
As I said in a previous message, if I recall correctly, I just compiled the python modules on diverse installations and collected them in the dmg afterwards. I did not do anything special to make them relocatable. So if they don't work now it is probably because of a change in the package and DYLD_LIBRARY_PATH is indeed the likely culprit. However, having it removed was a good change so it would be too bad to have to re-introduce it now... Maybe it would be time to ditch our custom osx-app.sh for something other people already use, e.g. http://sourceforge.net/apps/trac/gtk-osx/wiki/Bundle http://lists.macosforge.org/pipermail/macports-users/2007-February/001727.ht... or other python-based solutions.
JiHO --- http://maururu.net
3rd reply to the same thread. Sorry, I am catching up on a ton of email...
My current MacPorts prefix is '/Volumes/blue/mp'. '/opt/local' doesn't exist on my system.
That reminds me of another issue we have with the way we currently add items to the PATH. Right now, we are (well, I am, since I coded that part) brutal and stupid: just add "common" locations to the PATH and do not even try to deal with user-specific configuration.
In you case that could mean that, even though you probably configured your shell to use /Volumes/blue/tmp, Inkscape does not know about it. I suspect (but would welcome confirmation) that if you set the PATH in environment.plist: http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPRun... it should work. As far as I know, this is the standard way of setting environment variables for GUI apps on OS X.
However, even if you use environment.plist, you still need to set the PATH in the shell. If I understand this issue well, this is because Terminal will first execute bash and the system level bashrc resets the PATH. So, to recapitulate, when Terminal starts, since it is an regular OS X app, it has PATH set (from environment.plist), then it executes bash, which sets PATH to /usr/bin:/usr/sbin and not much else, then bash reads the user configuration file and does the PATH modifications set there.
Since Inkscape is a GUI app that starts with a shell script, the situation might be confusing and this is where some testing would be welcome.
In addition, there has been some debate (notably in the MacPorts community) about using environment.plist: why set environment variables in the plist if the shell, which is where you are most likely to use them, does not even honor them? The second issue is that you might want to keep your newest versions of ruby, python etc. for custom shell level stuff and make sure you don't break any major GUI app and keep the default system versions for those. I personally disagree with that: when you install newer versions of some software, you generally want to use it.
So to sum up, if setting stuff in environment.plsit works for Inkscape, I would be for writing a FAQ about setting PATH in environment.plist and remove our PATH stuff from the bin/inkscape script. Removing it will cause people to ask about what changed and this should diffuse knowledge of environment.plist.
Then, if someone comes with a clever way of extracting the PATH modifications from the shell configuration file of the user, that would be a plus, and would make things more transparent. However, this is no easy task: BASH alone has many possible user level config files (.profile, .bashrc, .bash_profile and there might be others). And then there are the csh, ksh aficionados ;)
Please let me know what you think,
JiHO --- http://maururu.net
On 29/10/09 22:10, JiHO wrote:
3rd reply to the same thread. Sorry, I am catching up on a ton of email...
Glad to have your input!
My current MacPorts prefix is '/Volumes/blue/mp'. '/opt/local' doesn't exist on my system.
That reminds me of another issue we have with the way we currently add items to the PATH. Right now, we are (well, I am, since I coded that part) brutal and stupid: just add "common" locations to the PATH and do not even try to deal with user-specific configuration.
In you case that could mean that, even though you probably configured your shell to use /Volumes/blue/tmp, Inkscape does not know about it. I suspect (but would welcome confirmation) that if you set the PATH in environment.plist: http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPRun... it should work. As far as I know, this is the standard way of setting environment variables for GUI apps on OS X.
No, I don't use 'environment.plist' - I don't like it because it is static and absolute (i.e. you can't append to system variables like $PATH and you need to logout/login again to get any changes picked up by the applications started by launchd). Even Apple says "The answer to your next question is: Yes, this is a relic left over from OpenStep/NextStep." http://developer.apple.com/mac/library/qa/qa2001/qa1067.html
<...>
So to sum up, if setting stuff in environment.plsit works for Inkscape, I would be for writing a FAQ about setting PATH in environment.plist and remove our PATH stuff from the bin/inkscape script. Removing it will cause people to ask about what changed and this should diffuse knowledge of environment.plist.
I would not recommend the use of 'environment.plist'.
Then, if someone comes with a clever way of extracting the PATH modifications from the shell configuration file of the user, that would be a plus, and would make things more transparent. However, this is no easy task: BASH alone has many possible user level config files (.profile, .bashrc, .bash_profile and there might be others). And then there are the csh, ksh aficionados ;)
I have been running your Inkscape development snapshots and later my own SVN builds with custom shell launcher scripts (script, openDoc and bin/inkscape), and have my normal shell environment (set with ~/.profile - a symbolic link to ~/.bash_profile - and ~/.bashrc) in Inkscape available by using a login shell in the first level (script and openDoc) which automatically sources the default startup files of my $SHELL (whatever that might be). See bug #383456 “[OS X] launch Inkscape with a login shell” https://bugs.launchpad.net/inkscape/+bug/383456 where I filed my initial ideas. That report is quite old and I have learned a lot since, but basically the attached patch is what gets the user configuration into the shell launcher script for inkscape-bin.
Please let me know what you think,
If this is something you might consider I could attach my current launch scripts to bug #383456 (status 'work-in-progress': additionally they log all inkscape console output into a separate file, add a time stamp, PID and list some env variables plus any arguments to inkscape-bin e.g. when called by a python extension script - mainly debugging info not of interest for the regular Inkscape user). I am sure using a login shell ('#!/bin/bash --login' or '#!/bin/sh -l') is debatable - OTOH X11/Xquartz does it as well as e.g. MacVim and probably other (ported) applications I don't know about.
~suv
On 29/10/09 23:22, ~suv wrote:
(...) by using a login shell in the first level (script and openDoc) which automatically sources the default startup files of my $SHELL (whatever that might be).
Here I am clearly wrong as it is unrelated to $SHELL. Based on the assumption that a) most users on OS X don't change their default shell (/bin/bash), and b) those who do are aware which startup files are sourced by login shells and know how to keep an updated ~/.profile even if they use bash, tcsh or zsh as default using '/bin/sh' or '/bin/bash' as login shell would however cover most cases (AFAIK bash is the default shell for new users since Tiger - or even Panther?). *If* the startup files of other shells like (t)csh, ksh and zsh need to be fully supported - a switch like X11/Xquartz[1] used in the launcher script could call 'bin/inkscape' with different login shells depending on the users default.
~suv
[1] http://cgit.freedesktop.org/xorg/xserver/tree/hw/xquartz/bundle/X11.sh
On Thu, Oct 29, 2009 at 23:22, ~suv <suv-sf@...58...> wrote:
I have been running your Inkscape development snapshots and later my own SVN builds with custom shell launcher scripts (script, openDoc and bin/inkscape), and have my normal shell environment (set with ~/.profile - a symbolic link to ~/.bash_profile - and ~/.bashrc) in Inkscape available by using a login shell in the first level (script and openDoc) which automatically sources the default startup files of my $SHELL (whatever that might be). See bug #383456 “[OS X] launch Inkscape with a login shell” https://bugs.launchpad.net/inkscape/+bug/383456 where I filed my initial ideas. That report is quite old and I have learned a lot since, but basically the attached patch is what gets the user configuration into the shell launcher script for inkscape-bin.
I never realized this. From your bug report, I would say that updating script exec would be the best solution but for now the bash --login will do. I'll commit that as soon as the trunk reopens.
Please let me know what you think,
If this is something you might consider I could attach my current launch scripts to bug #383456 (status 'work-in-progress': additionally they log all inkscape console output into a separate file, add a time stamp, PID and list some env variables plus any arguments to inkscape-bin e.g. when called by a python extension script - mainly debugging info not of interest for the regular Inkscape user).
This would be welcome indeed. I would suggest, however, to make it a new bug report/blueprint, assigned to me, that reads "Adding debugging output to Inkscape on OS X" or something.
Thanks a lot,
JiHO --- http://maururu.net
participants (4)
-
Chris Mohler -
JiHO -
Michael Wybrow -
~suv