zeroinstall-injector fails with pygtk problem

[wsc9tt@…]

The zeroinstall-injector package builds and installs fine but here is a sample from running it:

mbp ~ $ 0launch --gui
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/zeroinstall/0launch-gui/0launch-gui", line 11, in <module>
    import pygtk; pygtk.require('2.0')
ImportError: No module named pygtk

It appears to be missing some dependency.

This is from a fresh install of macports on a Leopard machine.

[wsc9tt@…]

Cc Me!

[wsc9tt@…]

Interesting. The first half of the problem is that zeroinstall was using the wrong python.

I don't have /opt/local/bin first in my path so it appears that 0install was relaunching python without using the macports version that is depends on. It either got the mac's /usr/bin/python or fink's /sw/bin/python2.5

When launching with the right PATH I get something like this:

mbp ~ $ PATH=/opt/local/bin:$PATH 0launch --gui The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY_YOU_MUST_EXEC() to debug. The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY_YOU_MUST_EXEC() to debug. The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY_YOU_MUST_EXEC() to debug. The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY_YOU_MUST_EXEC() to debug. The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY_YOU_MUST_EXEC() to debug.

where it then has a fault in python.

[afb@…]

Replying to wsc9tt@…:

Interesting. The first half of the problem is that zeroinstall was using the wrong python.

I don't have /opt/local/bin first in my path so it appears that 0install was relaunching python without using the macports version that is depends on. It either got the mac's /usr/bin/python or fink's /sw/bin/python2.5

Yes, you need to have MacPorts in your PATH. Will look at the Leopard problem later.

[wsc9tt@…]

Not just in your PATH, but first in your PATH. That is a bug IMHO. But it may be a bug with zeroinstall, I will test on linux.

[afb@…]

I meant first in your PATH, so that it won't use any other pythons...

I'm sure that it would fail on Linux too, if you installed it for one Python and then put another one first in your PATH. More of a general Python bug, but.

The other fork/exec problem is due to more strict enforcing in Leopard: ​http://developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html

I don't really see launch doing any tricky stuff before calling the exec, but it's possible that some of the string/path functions call CoreFoundation.

[afb@…]

No activity, closing bug.

[(none)]

Milestone Port Bugs deleted

[wsc9tt@…]

Funny, new machine, Snow Leopard, fresh install of MacPorts and one of the first things I tried is this:

$ PATH=/opt/local/bin:$PATH 0launch ​http://dl.dropbox.com/u/4893/feeds/sshuttle.xml Traceback (most recent call last):

File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/zeroinstall/0launch-gui/0launch-gui", line 13, in <module>

import pygtk; pygtk.require('2.0')

ImportError: No module named pygtk

And a google search tells me I have already reported this bug. ;-)

[afb@…]

If you run pygtk-demo, does that work OK ?

[afb@…]

Another way to get the same problem (besides not having MacPorts first in your $PATH), is to not have any python program (that is, not having run python_select python25) Zero Install assumes that it can use "#!/usr/bin/env python"

Guess it should be patched to run python with the absolute path and version to avoid these problems, something like: #!/opt/local/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python

[afb@…]

Fixed, r70137.

[wsc9tt@…]

Thanks. I was about to tell you that creating a symlink for 'python' in /opt/local/bin and putting that first on the path works. But now it works.

Now it seems my feed is busted... ;-)

[afb@…]

Replying to wsc9tt@…:

Thanks. I was about to tell you that creating a symlink for 'python' in /opt/local/bin and putting that first on the path works.

Yeah, that is what python_select does for you. If you don't run it, you end up with Apple's python.