Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #69112 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  calling Python script from another Python script (Windows, multiple installation problem) Martin Landa <landa.martin@gmail.com> - 2014-03-26 02:40 -0700
    Re: calling Python script from another Python script (Windows, multiple installation problem) Vlastimil Brom <vlastimil.brom@gmail.com> - 2014-03-26 12:40 +0100
      Re: calling Python script from another Python script (Windows, multiple installation problem) Martin Landa <landa.martin@gmail.com> - 2014-03-26 05:29 -0700
        Re: calling Python script from another Python script (Windows, multiple installation problem) Martin Landa <landa.martin@gmail.com> - 2014-03-26 05:49 -0700
          Re: calling Python script from another Python script (Windows, multiple installation problem) Chris Angelico <rosuav@gmail.com> - 2014-03-26 23:54 +1100
            Re: calling Python script from another Python script (Windows, multiple installation problem) Martin Landa <landa.martin@gmail.com> - 2014-03-26 06:11 -0700
          Re: calling Python script from another Python script (Windows, multiple installation problem) Cameron Simpson <cs@zip.com.au> - 2014-03-27 08:27 +1100

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

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 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

[toc] | [next] | [standalone]

#69115

2014-03-26 10:40 GMT+01:00 Martin Landa <landa.martin@gmail.com>:
> 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 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
> --
> https://mail.python.org/mailman/listinfo/python-list


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

[toc] | [prev] | [next] | [standalone]

#69121

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

[toc] | [prev] | [next] | [standalone]

#69122

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. Martin

[toc] | [prev] | [next] | [standalone]

#69123

On Wed, Mar 26, 2014 at 11:49 PM, Martin Landa <landa.martin@gmail.com> wrote:
>             # get full path including file extension for scripts
>             fcmd = get_real_command(args[0])

What's that function do?

ChrisA

[toc] | [prev] | [next] | [standalone]

#69124

Dne středa, 26. března 2014 13:54:02 UTC+1 Chris Angelico napsal(a):
> On Wed, Mar 26, 2014 at 11:49 PM, Martin Landa <landa.martin@gmail.com> wrote:
> 
> >             # 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.

[toc] | [prev] | [next] | [standalone]

#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>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web