Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder7.xlned.com!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Thu, 27 Mar 2014 08:27:32 +1100
From: Cameron Simpson <cs@zip.com.au>
To: Martin Landa <landa.martin@gmail.com>
Subject: Re: calling Python script from another Python script (Windows, multiple installation problem)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6ba81449-5f4c-46be-ad4a-64ea8bc5b436@googlegroups.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
References: <6ba81449-5f4c-46be-ad4a-64ea8bc5b436@googlegroups.com>
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8589.1395869262.18130.python-list@python.org>
Lines: 44
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:69146

On 26Mar2014 05:49, Martin Landa <landa.martin@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@zip.com.au>

Carpe Datum     - John Sloan <jsloan@ncar.ucar.edu>