calling Python script from another Python script (Windows, multiple installation problem)

Cameron Simpson cs at zip.com.au
Wed Mar 26 17:27:32 EDT 2014


On 26Mar2014 05:49, Martin Landa <landa.martin at gmail.com> wrote:
> 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,
-- 
Cameron Simpson <cs at zip.com.au>

Carpe Datum     - John Sloan <jsloan at ncar.ucar.edu>



More information about the Python-list mailing list