xpra gets confused when a python virtual environment is active about xpra HOT 7 CLOSED

To be quick, I have just applied the patch to the "installed" file on my machine, rather than rebuilding a package for xpra.

Seems OK!

Thanks for the attention and for being extra quick!

from xpra.

then xpra startx misbehaving.

xpra does not use startx.

launch run_scaled xpra

That's a strange command to run.

Is the /usr/bin/xpra installed correctly?
https://github.com/Xpra-org/xpra/blob/master/fs/bin/xpra

it may not be running under the correct python interpreter or that there is no module named xpra

IIRC, run_scaled uses --attach=yes.
The initial command will start the server and spawn a separate client command to attach to it.
Perhaps it is using the wrong interpreter for doing that?

Maybe the problem comes from here:

I don't know how else to locate the correct interpreter to run.

from xpra.

Sorry many typos, in my report, should look better now

from xpra.

Perhaps it is using the wrong interpreter for doing that?

My wild guess is that the server launches fine, but then the client uses the python from the virtual environment. That is actually the same python interpreter on my system, but with a different setup for the packages paths... As a consequence xpra ends up not being able to find its own module...

from xpra.

That is actually the same python interpreter on my system, but with a different setup for the packages paths...

Like I said, I don't see how xpra is supposed to figure out which executable and PYTHONPATH to use.

This does not look like a bug to me.

from xpra.

The problem does not seem to be the python executable, but the prefix by which it gets called because of the following:

1. python sets sys.path using sys.prefix that in turn gets set from the path by which the python interpreter is called. For instance, if you launch /usr/bin/python3 then sys.prefix gets set to /usr, but if you have a virtual environment active, calling just python will end up in sys.prefix being the path of the virtual environment itself, so sys.path will be set up differently.

2. when you call xpra, you call a shell script that has a shell bang pointing to /usr/bin/python3. So you get sys.prefix set up to the prefix of the system python and sys.path containing the directory where xpra can be found. However, when xpra (server) tries to launch xpra (client), your code determines pythonx.y as the interpreter to start, without any absolute path. In turn that ends up calling the python of the virtual environment, which causes sys.prefix to be set to the virtual environment itself and sys.path not to include the location of the xpra module.

I think that the path of the interpreter to call should be based on:

• sys.executable when not empty
  • this assures that the same interpreter at the same path is used for the server and the client
• sys.prefix/bin/pythonx.y otherwise where the pythonx.y string is determined as in your code
  • this is the best guess should sys.executable not be set, as it sets the path of the interpreter correctly

from xpra.

@callegar does the commit above fix things?

from xpra.