On 26Mar2014 05:49, Martin Landa <landa.mar...@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 <c...@zip.com.au>
Carpe Datum - John Sloan <jsl...@ncar.ucar.edu>
--
https://mail.python.org/mailman/listinfo/python-list
