Xpra should not pollute the environment variable namespace with python specific vars (e.g., PYTHONHOME).
I was testing Xpra in my Mac OS X environment and was surprised to see this error:
Traceback (most recent call last): File "/Users/krader/bin/ssh", line 10, in <module> from lib.python import session_loader File "/Users/krader/lib/python/session_loader.py", line 8, in <module> import argparse ImportError: No module named argparse
The case is the Xpra shell script wrapper exports PYTHONHOME and a modified PYTHONPATH. I happen to have a python wrapper around the /usr/bin/ssh command in my PATH and it was broken by those environment vars. Those environment vars are not necessary and should not be set. See, for example, how Conda (http://conda.pydata.org) handles this.
Does the Xpra shell script (found in
Xpra.app/Contents/MacOS) continue to work if the
exports are taken out? (looks like it should)
BTW, I fail to see what conda has to do with it. Where shall I be looking?
(alternatively, we could replace the
PYTHONPATH modifications with more embedded python code that modifies
Why things are done this way at present:
r6689 should fix this, does this work for you?
You can find a beta build with this change here: http://xpra.org/beta/osx/x86/
Thanks for taking a stab at fixing this but the fix makes matters worse. Using the new Xpra script results in these error messages:
ERROR: gtkosx_application module is missing - trying to continue anyway xpra main exception: No module named gi.repository
I've got a fix mostly completed. The PYTHONHOME var isn't needed at all. Two directories need to be added to sys.path. I've tested a solution that uses a sitecustomize.py module rather than the PYTHONPATH env var and a cleaned up Xpra script. I'm now working on figuring out how to incorporate that into your build scripts.
Conda is a new python package manager that is almost certainly going to supplant virtualenv and possibly pip. I mentioned it only as an example of how to create self contained python environments that don't require setting PYTHONHOME or PYTHONPATH. You can ignore that comment.
P.S., You can't simply remove the export command from the script. If you do the vars aren't available to the spawned processes which need them.
P.P.S., It appears that these scripts haven't received much attention. They're full of things that aren't needed (e.g., checking for the PPC architecture) or horribly inefficient. Also, the Xpra_Launcher script doesn't even run. It emits this error:
ImportError: No module named client_launcher
Doh, I only tested on a system which had xpra installed in its local python... so it looked like it still worked. Reverted in r6692.
I will wait for your patch instead.
I'm now working on figuring out how to incorporate that into your build scripts
Please post what you have, maybe we can help.
It appears that these scripts haven't received much attention
That's correct! The whole thing is very brittle unfortunately.
checking for the PPC architecture
In the build scripts, yes. We used to provide PPC
DMGs when I still owned a PPC mac. This can be dropped now I think.
or horribly inefficient
That's quite possible! Where?
Xpra_Launcher script doesn't even run
This should be fixed in r6693 (will backport), sorry about that. I never thought of double-clicking the app before the release! (I only ever use the command line, often scripted..)
Not heard back, closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/590