calling Python script from another Python script (Windows, multipleinstallation problem)

[Martin Landa]

Hi all,

I am trying to fix a bug in the project which I am working for. The programstarts on Windows via bat file which calls a Python script to set up the environment including GUI and allow to launch program-specific tools. Some of the tools are written in C, some in Python. These commands are run via subprocess.Popen class. The Windows installer comes with its own bundled Python which is usually different from possible system-wide Python. This is source of the problems, Python scripts run via subprocess.Popen are launched via system-wide Python version, not desired bundled Python. Except hacks like `Popen(sys.executable, ...)` I am looking for a better solution. I checked virtualenv [1] or Pylauncher [2] but without success, speaking about Python2 not Python3 which comes from version 3.3 with intergrated pylauncher...

Thanks in advance for any ideas, suggestions or pointers! Martin

[1] http://www.virtualenv.org/en/latest/
[2] https://bitbucket.org/vinay.sajip/pylauncher

 

[Vlastimil Brom]

Hi all,

I am trying to fix a bug in the project which I am working for. The program starts on Windows via bat file which calls a Python script to set up theenvironment including GUI and allow to launch program-specific tools. Someof the tools are written in C, some in Python. These commands are run via subprocess.Popen class. The Windows installer comes with its own bundled Python which is usually different from possible system-wide Python. This is source of the problems, Python scripts run via subprocess.Popen are launchedvia system-wide Python version, not desired bundled Python. Except hacks like `Popen(sys.executable, ...)` I am looking for a better solution. I checked virtualenv [1] or Pylauncher [2] but without success, speaking about Python2 not Python3 which comes from version 3.3 with intergrated pylauncher....

Thanks in advance for any ideas, suggestions or pointers! Martin

[1] http://www.virtualenv.org/en/latest/
[2] https://bitbucket.org/vinay.sajip/pylauncher

Hi,
I'm probably missing some requirement of your use case, but I guess,
it should be possible to specify the path of the desired python
interpreter along with the executed script as an argument to
Popen(...). This should make the selection of the used python
explicit.
Or are there any other disadvantages of the current approach, which
you are solving in parallel?

hth,
vbr

 

[Martin Landa]

Hi,

it should be possible to specify the path of the desired python

interpreter along with the executed script as an argument to

Popen(...). This should make the selection of the used python

explicit.

Or are there any other disadvantages of the current approach, which

you are solving in parallel?

not really, I am just searching for a better solution based on virtualenv or something similar...

Thanks, Martin

 

[Martin Landa]

Dne středa, 26. března 2014 13:29:47 UTC+1 Martin Landa napsal(a):

not really, I am just searching for a better solution based on virtualenvor something similar...

particularly I am using something like

if sys.platform == "win32":
# get full path including file extension for scripts
fcmd = get_real_command(args[0])
if fcmd.endswith('.py'):
args[0] = fcmd
args.insert(0, sys.executable)

where 'args' in subprocess.Popen's argument. I just wonder if there is a better or preferable solution over this kind of a hack. Martin

 

[Chris Angelico]

# get full path including file extension for scripts
fcmd = get_real_command(args[0])

What's that function do?

ChrisA

 

[Martin Landa]

Dne středa, 26. března 2014 13:54:02 UTC+1 Chris Angelico napsal(a):

# get full path including file extension for scripts

fcmd = get_real_command(args[0])

this function returns a full path including file extension for scripts. If 'args[0]' is a binary file in the path, it returns 'args[0]'. If 'args[0]' is detected as a script (it finds in the search path file with such name and given extension, eg. `py`) it returns full path to the file, /path/to/file/args[0].py.

 

[Cameron Simpson]

Dne středa, 26. března 2014 13:29:47 UTC+1 Martin Landa napsal(a):

not really, I am just searching for a better solution based on virtualenv or something similar...

particularly I am using something like

if sys.platform == "win32":
# get full path including file extension for scripts
fcmd = get_real_command(args[0])
if fcmd.endswith('.py'):
args[0] = fcmd
args.insert(0, sys.executable)

where 'args' in subprocess.Popen's argument. I just wonder if
there is a better or preferable solution over this kind of a hack.

Personally, the above is what I would do in your situation.

Any solution involving virtualenv or the like will still need to
point at the right python executable. Provided your code above is
in a handy function, I wouldn't modify it.

What virtualenv (presumably a virtualenv bundled in your package)
_will_ give you is a stable and predictable collection of library
files to go with your python interpreter. That could well be a
significant benefit, especially in the face or an unknown target
machine.

So you may have a good case for putting a virtualenv in your bundle,
but still using the _same_ code above to invoke stuff - the python
in the virtualenv will set its sys.path, so the easy way is to
use your existing code to access the virtualenv python executable.

The only catch is that I do not know how mobile a virtualenv is;
if your bundle is unpacked in an unknown temporary location,
maybe virtualenv won't work correctly. Needs testing.

Disclaimer: I'm a UNIX guy.

Just my 2c. Hope it is helpful,