Re: [PyInstaller] Python, Windows and no console environments

2017-03-31 Thread Coyot Linden (Glenn Glazer) 

  
  
You're welcome!
  
  Best,
  
  coyot
  
  On 3/31/17 03:03, Jones, Bryan wrote:


  Aargh, you're correct. Thanks for the catch! Fixed.


Bryan
  
  
On Thu, Mar 30, 2017 at 3:55 PM, Coyot
  Linden (Glenn Glazer)  wrote:
  

  Oh, and
I found another bug in the recipe.  In:

ret = {'stdout:': subprocess.PIPE}

There is an extra colon inside the key.  Since
subprocess doesn't know what 'stdout:', this causes its
init() to throw a type exception.

Best,

coyot

On 3/27/17 14:48, Jones, Bryan wrote:
  
  
Thanks, fixed!

  On Mon, Mar 20, 2017 at 3:40
PM, Coyot Linden (Glenn Glazer) 
wrote:

  
On
  3/20/17 12:01, Coyot Linden (Glenn Glazer)
  wrote:


  On
3/16/17 10:07, Jones, Bryan wrote:
  
  This link might be
relevant -- https://github.com/pyinstaller/pyinstaller/wiki/Recipe-subprocess


Have you tried those suggestions?
  


One other quick note: the recipe calls for half
  a pound of sugar a hasattr test that
sets an isFrozen variable that is actually never
used in the code or test code.

Best,

coyot

  

  

  

  






  


  




-- 
You received this message because you are subscribed to the Google Groups "PyInstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyinstaller+unsubscr...@googlegroups.com.
To post to this group, send email to pyinstaller@googlegroups.com.
Visit this group at https://groups.google.com/group/pyinstaller.
For more options, visit https://groups.google.com/d/optout.

Re: [PyInstaller] Python, Windows and no console environments

2017-03-31 Thread Jones, Bryan 
Aargh, you're correct. Thanks for the catch! Fixed.

Bryan

On Thu, Mar 30, 2017 at 3:55 PM, Coyot Linden (Glenn Glazer) <
co...@lindenlab.com> wrote:

> Oh, and I found another bug in the recipe.  In:
>
> ret = {'stdout:': subprocess.PIPE}
>
> There is an extra colon inside the key.  Since subprocess doesn't know
> what 'stdout:', this causes its init() to throw a type exception.
>
> Best,
>
> coyot
>
> On 3/27/17 14:48, Jones, Bryan wrote:
>
> Thanks, fixed!
>
> On Mon, Mar 20, 2017 at 3:40 PM, Coyot Linden (Glenn Glazer) <
> co...@lindenlab.com> wrote:
>
>> On 3/20/17 12:01, Coyot Linden (Glenn Glazer) wrote:
>>
>> On 3/16/17 10:07, Jones, Bryan wrote:
>>
>> This link might be relevant -- https://github.com/pyinstal
>> ler/pyinstaller/wiki/Recipe-subprocess
>>
>> Have you tried those suggestions?
>>
>>
>> One other quick note: the recipe calls for half a pound of sugar a
>> hasattr test that sets an isFrozen variable that is actually never used in
>> the code or test code.
>>
>> Best,
>>
>> coyot
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "PyInstaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pyinstaller+unsubscr...@googlegroups.com.
> To post to this group, send email to pyinstaller@googlegroups.com.
> Visit this group at https://groups.google.com/group/pyinstaller.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Bryan A. Jones, Ph.D.
Associate Professor
Department of Electrical and Computer Engineering
231 Simrall / PO Box 9571
Mississippi State University
Mississippi state, MS 39762
http://www.ece.msstate.edu/~bjones
bjones AT ece DOT msstate DOT edu
voice 662-325-3149
fax 662-325-2298

Our Master, Jesus Christ, is on his way. He'll show up right on
time, his arrival guaranteed by the Blessed and Undisputed Ruler,
High King, High God.
- 1 Tim. 6:14b-15 (The Message)

-- 
You received this message because you are subscribed to the Google Groups 
"PyInstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pyinstaller+unsubscr...@googlegroups.com.
To post to this group, send email to pyinstaller@googlegroups.com.
Visit this group at https://groups.google.com/group/pyinstaller.
For more options, visit https://groups.google.com/d/optout.

Re: [PyInstaller] Python, Windows and no console environments

2017-03-30 Thread Coyot Linden (Glenn Glazer) 

  
  
Oh, and I found another bug in the
  recipe.  In:
  
  ret = {'stdout:': subprocess.PIPE}
  
  There is an extra colon inside the key.  Since subprocess doesn't
  know what 'stdout:', this causes its init() to throw a type
  exception.
  
  Best,
  
  coyot
  
  On 3/27/17 14:48, Jones, Bryan wrote:


  Thanks, fixed!
  
On Mon, Mar 20, 2017 at 3:40 PM, Coyot
  Linden (Glenn Glazer)  wrote:
  

  On
3/20/17 12:01, Coyot Linden (Glenn Glazer) wrote:
  
  
On
  3/16/17 10:07, Jones, Bryan wrote:

This link might be relevant -- https://github.com/pyinstaller/pyinstaller/wiki/Recipe-subprocess
  
  
  Have you tried those suggestions?

  
  
  One other quick note: the recipe calls for half a
pound of sugar a hasattr test that sets an
  isFrozen variable that is actually never used in the code
  or test code.
  
  Best,
  
  coyot

  

  


  




-- 
You received this message because you are subscribed to the Google Groups "PyInstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyinstaller+unsubscr...@googlegroups.com.
To post to this group, send email to pyinstaller@googlegroups.com.
Visit this group at https://groups.google.com/group/pyinstaller.
For more options, visit https://groups.google.com/d/optout.

Re: [PyInstaller] Python, Windows and no console environments

2017-03-27 Thread Jones, Bryan 
Thanks, fixed!

On Mon, Mar 20, 2017 at 3:40 PM, Coyot Linden (Glenn Glazer) <
co...@lindenlab.com> wrote:

> On 3/20/17 12:01, Coyot Linden (Glenn Glazer) wrote:
>
> On 3/16/17 10:07, Jones, Bryan wrote:
>
> This link might be relevant -- https://github.com/
> pyinstaller/pyinstaller/wiki/Recipe-subprocess
>
> Have you tried those suggestions?
>
>
> One other quick note: the recipe calls for half a pound of sugar a
> hasattr test that sets an isFrozen variable that is actually never used in
> the code or test code.
>
> Best,
>
> coyot
>
> --
> You received this message because you are subscribed to the Google Groups
> "PyInstaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pyinstaller+unsubscr...@googlegroups.com.
> To post to this group, send email to pyinstaller@googlegroups.com.
> Visit this group at https://groups.google.com/group/pyinstaller.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Bryan A. Jones, Ph.D.
Associate Professor
Department of Electrical and Computer Engineering
231 Simrall / PO Box 9571
Mississippi State University
Mississippi state, MS 39762
http://www.ece.msstate.edu/~bjones
bjones AT ece DOT msstate DOT edu
voice 662-325-3149
fax 662-325-2298

Our Master, Jesus Christ, is on his way. He'll show up right on
time, his arrival guaranteed by the Blessed and Undisputed Ruler,
High King, High God.
- 1 Tim. 6:14b-15 (The Message)

-- 
You received this message because you are subscribed to the Google Groups 
"PyInstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pyinstaller+unsubscr...@googlegroups.com.
To post to this group, send email to pyinstaller@googlegroups.com.
Visit this group at https://groups.google.com/group/pyinstaller.
For more options, visit https://groups.google.com/d/optout.

Re: [PyInstaller] Python, Windows and no console environments

2017-03-20 Thread Coyot Linden (Glenn Glazer) 

  
  
On 3/20/17 12:01, Coyot Linden (Glenn
  Glazer) wrote:


  On 3/16/17 10:07, Jones, Bryan wrote:
  
  This link might be relevant -- https://github.com/pyinstaller/pyinstaller/wiki/Recipe-subprocess


Have you tried those suggestions?
  


One other quick note: the recipe calls for half a pound of
  sugar a hasattr test that sets an isFrozen variable that
is actually never used in the code or test code.

Best,

coyot
  




-- 
You received this message because you are subscribed to the Google Groups "PyInstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyinstaller+unsubscr...@googlegroups.com.
To post to this group, send email to pyinstaller@googlegroups.com.
Visit this group at https://groups.google.com/group/pyinstaller.
For more options, visit https://groups.google.com/d/optout.

Re: [PyInstaller] Python, Windows and no console environments

2017-03-16 Thread Jones, Bryan 
Steve,

Great idea -- thanks!

Bryan

On Thu, Mar 16, 2017 at 12:51 PM, Steve Barnes 
wrote:

> I have also raised an issue on the cpython manuals,
> http://bugs.python.org/issue29829, requesting a note be added to the
> subprocess documentation.
>
> Steve
>
> On 16/03/2017 17:24, Coyot Linden (Glenn Glazer) wrote:
> > No, I hadn't seen that.
> >
> > Thanks for the pointer!
> >
> > Best,
> >
> > coyot
> >
> >
> > On 3/16/17 10:07, Jones, Bryan wrote:
> >> This link might be relevant
> >> -- https://github.com/pyinstaller/pyinstaller/wiki/Recipe-subprocess
> >>
> >> Have you tried those suggestions?
> >>
> >> On Thu, Mar 16, 2017 at 10:47 AM, Coyot Linden (Glenn Glazer)
> >> > wrote:
> >>
> >> We discovered that code which ran perfectly correctly by executing
> >> the scripts in the POSIX environment or via python on the Windows
> >> command prompt would fail when compiled using the -w flag to
> >> PyInstaller. This flag prevents the application from launching a
> >> console window when the application starts, which we clearly did
> >> not want with our client. The problem occurs when a caller
> >> executes Python's subprocess and the caller tries to implicitly or
> >> explictly access stderr or stdin on Windows.
> >>
> >> Because this originally occurred in our code with a caller of an
> >> imported module our test code used that mode.  We believe it can
> >> be reproduced without the caller.
> >>
> >> We also believe that this error is a deep down result in the
> >> pythonw implementation on Windows and PyInstaller just makes it
> >> more obvious.  Some trials suggest that pythonw produces the same
> >> failure cases, albeit with somewhat different output.
> >>
> >> To the PyInstaller team: we found (and is reproducible with the
> >> code in the appendices below) that even with -w, a console window
> >> flashes for a tiny fraction of a second.  Is there any way to
> >> eliminate that completely?
> >>
> >> -
> >>
> >> So beginning with code that fails that shows the example, we have:
> >>
> >> Sample problematic caller code:
> >>
> >> #!/usr/bin/env python
> >>
> >> import cgitb
> >> import os.path
> >> import subwrapper
> >> import sys
> >>
> >> cwd = os.path.dirname(os.path.realpath(str(sys.executable)))
> >> cgitb.enable(logdir=cwd, format='text')
> >>
> >> print subwrapper.getMachineID()
> >>
> >> Sample problematic imported module code:
> >>
> >> #!/usr/bin/env python
> >>
> >> import subprocess
> >>
> >> def getMachineID():
> >>return subprocess.check_output(['wmic','csproduct','get','UUID'
> ])
> >>
> >>  Sample output under python:
> >>
> >> >python caller.py
> >> UUID
> >> D8F59000-4F39---
> >>
> >> Sample output when compiled with the -y --clean --onefile flags:
> >>
> >> >caller.exe
> >> UUID
> >> D8F59000-4F39---
> >>
> >> Sample output when compiled with the -y -w --clean --onefile flags:
> >>
> >> No output.  Failure to execute script window appears (the name
> >> depends on the script name):
> >>
> >>
> >>
> >> Note that this error message is specific to PyInstaller, it comes
> >> from
> >> https://github.com/pyinstaller/pyinstaller/blob/
> a70b20e4de6a6817987d28ca9f3201c8105fd858/bootloader/src/pyi_launch.c#L411
> >>  a70b20e4de6a6817987d28ca9f3201c8105fd858/bootloader/src/pyi_launch.c#L411>
> >> .
> >>
> >> As noted above, we ran the toy scripts under cgitb tracing to
> >> obtain detailed call stack information which does not normally
> >> appear when that Window appears.  Full cgitb output is below, but
> >> the important part is:
> >>
> >> Traceback (most recent call last):
> >>   File "caller.py", line 11, in 
> >>   File "subwrapper.py", line 6, in getMachineID
> >>   File "subprocess.py", line 566, in check_output
> >>   File "subprocess.py", line 702, in __init__
> >>   File "subprocess.py", line 823, in _get_handles
> >> WindowsError: [Error 6] The handle is invalid
> >>
> >> Researching that error message led us to:
> >>
> >> https://github.com/incuna/django-wkhtmltopdf/issues/91#
> issuecomment-179080434
> >>  issuecomment-179080434>
> >>
> >> which points at the problem being related to the passing of
> >> filehandles, but suggests hacking subprocess.py, which we were
> >> extremely reluctant to do for production software.
> >>
> >> We also found:
> >>
> >> http://stackoverflow.com/questions/337870/python-
> subprocess-call-fails-when-using-pythonw-exe
> >>  subprocess-call-fails-when-using-pythonw-exe>
> >>
> >> which

Re: [PyInstaller] Python, Windows and no console environments

2017-03-16 Thread Coyot Linden (Glenn Glazer) 
Good to know, Steve.  After flailing at this for a couple of days, it's 
good to see someone else describe this as "hard to debug"!


Pity there isn't any kind of voting method on Python Tracker, I'd surely 
+1 this one.


Best,

coyot

On 3/16/17 10:51, Steve Barnes wrote:

I have also raised an issue on the cpython manuals,
http://bugs.python.org/issue29829, requesting a note be added to the
subprocess documentation.

Steve

On 16/03/2017 17:24, Coyot Linden (Glenn Glazer) wrote:

No, I hadn't seen that.

Thanks for the pointer!

Best,

coyot


On 3/16/17 10:07, Jones, Bryan wrote:

This link might be relevant
-- https://github.com/pyinstaller/pyinstaller/wiki/Recipe-subprocess

Have you tried those suggestions?

On Thu, Mar 16, 2017 at 10:47 AM, Coyot Linden (Glenn Glazer)
> wrote:

 We discovered that code which ran perfectly correctly by executing
 the scripts in the POSIX environment or via python on the Windows
 command prompt would fail when compiled using the -w flag to
 PyInstaller. This flag prevents the application from launching a
 console window when the application starts, which we clearly did
 not want with our client. The problem occurs when a caller
 executes Python's subprocess and the caller tries to implicitly or
 explictly access stderr or stdin on Windows.

 Because this originally occurred in our code with a caller of an
 imported module our test code used that mode.  We believe it can
 be reproduced without the caller.

 We also believe that this error is a deep down result in the
 pythonw implementation on Windows and PyInstaller just makes it
 more obvious.  Some trials suggest that pythonw produces the same
 failure cases, albeit with somewhat different output.

 To the PyInstaller team: we found (and is reproducible with the
 code in the appendices below) that even with -w, a console window
 flashes for a tiny fraction of a second.  Is there any way to
 eliminate that completely?

 -

 So beginning with code that fails that shows the example, we have:

 Sample problematic caller code:

 #!/usr/bin/env python

 import cgitb
 import os.path
 import subwrapper
 import sys

 cwd = os.path.dirname(os.path.realpath(str(sys.executable)))
 cgitb.enable(logdir=cwd, format='text')

 print subwrapper.getMachineID()

 Sample problematic imported module code:

 #!/usr/bin/env python

 import subprocess

 def getMachineID():
return subprocess.check_output(['wmic','csproduct','get','UUID'])

  Sample output under python:

 >python caller.py
 UUID
 D8F59000-4F39---

 Sample output when compiled with the -y --clean --onefile flags:

 >caller.exe
 UUID
 D8F59000-4F39---

 Sample output when compiled with the -y -w --clean --onefile flags:

 No output.  Failure to execute script window appears (the name
 depends on the script name):



 Note that this error message is specific to PyInstaller, it comes
 from
 
https://github.com/pyinstaller/pyinstaller/blob/a70b20e4de6a6817987d28ca9f3201c8105fd858/bootloader/src/pyi_launch.c#L411
 

 .

 As noted above, we ran the toy scripts under cgitb tracing to
 obtain detailed call stack information which does not normally
 appear when that Window appears.  Full cgitb output is below, but
 the important part is:

 Traceback (most recent call last):
   File "caller.py", line 11, in 
   File "subwrapper.py", line 6, in getMachineID
   File "subprocess.py", line 566, in check_output
   File "subprocess.py", line 702, in __init__
   File "subprocess.py", line 823, in _get_handles
 WindowsError: [Error 6] The handle is invalid

 Researching that error message led us to:

 
https://github.com/incuna/django-wkhtmltopdf/issues/91#issuecomment-179080434
 


 which points at the problem being related to the passing of
 filehandles, but suggests hacking subprocess.py, which we were
 extremely reluctant to do for production software.

 We also found:

 
http://stackoverflow.com/questions/337870/python-subprocess-call-fails-when-using-pythonw-exe
 


 which states

 /"sys.stdin and sys.stdout handles are invalid because pythonw
 does not provide console support as it runs as a deamon, so
 default arguments of subprocess.call() are failing.//
 //
 //Deamon (sic) programs close stdin/stdout/stderr purposedly and
 use logging instead, so that you have to manage this yourself: I

Re: [PyInstaller] Python, Windows and no console environments

2017-03-16 Thread Steve Barnes 
I have also raised an issue on the cpython manuals, 
http://bugs.python.org/issue29829, requesting a note be added to the 
subprocess documentation.

Steve

On 16/03/2017 17:24, Coyot Linden (Glenn Glazer) wrote:
> No, I hadn't seen that.
>
> Thanks for the pointer!
>
> Best,
>
> coyot
>
>
> On 3/16/17 10:07, Jones, Bryan wrote:
>> This link might be relevant
>> -- https://github.com/pyinstaller/pyinstaller/wiki/Recipe-subprocess
>>
>> Have you tried those suggestions?
>>
>> On Thu, Mar 16, 2017 at 10:47 AM, Coyot Linden (Glenn Glazer)
>> > wrote:
>>
>> We discovered that code which ran perfectly correctly by executing
>> the scripts in the POSIX environment or via python on the Windows
>> command prompt would fail when compiled using the -w flag to
>> PyInstaller. This flag prevents the application from launching a
>> console window when the application starts, which we clearly did
>> not want with our client. The problem occurs when a caller
>> executes Python's subprocess and the caller tries to implicitly or
>> explictly access stderr or stdin on Windows.
>>
>> Because this originally occurred in our code with a caller of an
>> imported module our test code used that mode.  We believe it can
>> be reproduced without the caller.
>>
>> We also believe that this error is a deep down result in the
>> pythonw implementation on Windows and PyInstaller just makes it
>> more obvious.  Some trials suggest that pythonw produces the same
>> failure cases, albeit with somewhat different output.
>>
>> To the PyInstaller team: we found (and is reproducible with the
>> code in the appendices below) that even with -w, a console window
>> flashes for a tiny fraction of a second.  Is there any way to
>> eliminate that completely?
>>
>> -
>>
>> So beginning with code that fails that shows the example, we have:
>>
>> Sample problematic caller code:
>>
>> #!/usr/bin/env python
>>
>> import cgitb
>> import os.path
>> import subwrapper
>> import sys
>>
>> cwd = os.path.dirname(os.path.realpath(str(sys.executable)))
>> cgitb.enable(logdir=cwd, format='text')
>>
>> print subwrapper.getMachineID()
>>
>> Sample problematic imported module code:
>>
>> #!/usr/bin/env python
>>
>> import subprocess
>>
>> def getMachineID():
>>return subprocess.check_output(['wmic','csproduct','get','UUID'])
>>
>>  Sample output under python:
>>
>> >python caller.py
>> UUID
>> D8F59000-4F39---
>>
>> Sample output when compiled with the -y --clean --onefile flags:
>>
>> >caller.exe
>> UUID
>> D8F59000-4F39---
>>
>> Sample output when compiled with the -y -w --clean --onefile flags:
>>
>> No output.  Failure to execute script window appears (the name
>> depends on the script name):
>>
>>
>>
>> Note that this error message is specific to PyInstaller, it comes
>> from
>> 
>> https://github.com/pyinstaller/pyinstaller/blob/a70b20e4de6a6817987d28ca9f3201c8105fd858/bootloader/src/pyi_launch.c#L411
>> 
>> 
>> .
>>
>> As noted above, we ran the toy scripts under cgitb tracing to
>> obtain detailed call stack information which does not normally
>> appear when that Window appears.  Full cgitb output is below, but
>> the important part is:
>>
>> Traceback (most recent call last):
>>   File "caller.py", line 11, in 
>>   File "subwrapper.py", line 6, in getMachineID
>>   File "subprocess.py", line 566, in check_output
>>   File "subprocess.py", line 702, in __init__
>>   File "subprocess.py", line 823, in _get_handles
>> WindowsError: [Error 6] The handle is invalid
>>
>> Researching that error message led us to:
>>
>> 
>> https://github.com/incuna/django-wkhtmltopdf/issues/91#issuecomment-179080434
>> 
>> 
>>
>> which points at the problem being related to the passing of
>> filehandles, but suggests hacking subprocess.py, which we were
>> extremely reluctant to do for production software.
>>
>> We also found:
>>
>> 
>> http://stackoverflow.com/questions/337870/python-subprocess-call-fails-when-using-pythonw-exe
>> 
>> 
>>
>> which states
>>
>> /"sys.stdin and sys.stdout handles are invalid because pythonw
>> does not provide console support as it runs as a deamon, so
>> default arguments of subprocess.call() are failing.//
>> //
>> //Deamon (sic) programs close stdin/stdout/stderr purposedly and
>> use logging instead, so that you have to manage this yourself: I
>>

Re: [PyInstaller] Python, Windows and no console environments

2017-03-16 Thread Coyot Linden (Glenn Glazer) 

  
  
No, I hadn't seen that.
  
  Thanks for the pointer!
  
  Best,
  
  coyot
  
  
  On 3/16/17 10:07, Jones, Bryan wrote:


  This link might be relevant -- https://github.com/pyinstaller/pyinstaller/wiki/Recipe-subprocess


Have you tried those suggestions?
  
  
On Thu, Mar 16, 2017 at 10:47 AM, Coyot
  Linden (Glenn Glazer)  wrote:
  
 We discovered that
  code which ran perfectly correctly by executing the
  scripts in the POSIX environment or via python on the
  Windows command prompt would fail when compiled using the
  -w flag to PyInstaller. This flag prevents the application
  from launching a console window when the application
  starts, which we clearly did not want with our client. The
  problem occurs when a caller executes Python's subprocess
  and the caller tries to implicitly or explictly access
  stderr or stdin on Windows.
  
  Because this originally occurred in our code with a caller
  of an imported module our test code used that mode.  We
  believe it can be reproduced without the caller.  
  
  We also believe that this error is a deep down result in
  the pythonw implementation on Windows and PyInstaller just
  makes it more obvious.  Some trials suggest that pythonw
  produces the same failure cases, albeit with somewhat
  different output.
  
  To the PyInstaller team: we found (and is reproducible
  with the code in the appendices below) that even with -w,
  a console window flashes for a tiny fraction of a second. 
  Is there any way to eliminate that completely?
  
  -
  
  So beginning with code that fails that shows the example,
  we have:
  
  Sample problematic caller code:
  
  #!/usr/bin/env python

import cgitb
import os.path
import subwrapper
import sys

cwd = os.path.dirname(os.path.realpath(str(sys.executable)))
cgitb.enable(logdir=cwd, format='text')

print subwrapper.getMachineID()
  
  Sample problematic imported module code:
  
  #!/usr/bin/env python

import subprocess

def getMachineID():
   return subprocess.check_output(['wmic','csproduct','get','UUID'])
  
   Sample output under python:
  
  >python caller.py
UUID
D8F59000-4F39---
  
  Sample output when compiled with the -y --clean --onefile
  flags:
  
  >caller.exe
  UUID
  D8F59000-4F39---
  
  Sample output when compiled with the -y -w --clean
  --onefile flags:
  
  No output.  Failure to execute script window appears (the
  name depends on the script name):
  
  
  
  Note that this error message is specific to PyInstaller,
  it comes from https://github.com/pyinstaller/pyinstaller/blob/a70b20e4de6a6817987d28ca9f3201c8105fd858/bootloader/src/pyi_launch.c#L411
  .
  
  As noted above, we ran the toy scripts under cgitb tracing
  to obtain detailed call stack information which does not
  normally appear when that Window appears.  Full cgitb
  output is below, but the important part is:
  
  Traceback (most recent call last):
    File "caller.py", line 11, in 
    File "subwrapper.py", line 6, in getMachineID
    File "subprocess.py", line 566, in check_output
    File "subprocess.py", line 702, in __init__
    File "subprocess.py", line 823, in _get_handles
  WindowsError: [Error 6] The handle is invalid
  
  Researching that error message led us to: 
  
  https://github.com/incuna/django-wkhtmltopdf/issues/91#issuecomment-179080434
  
  which points at the problem being related to the passing
  of filehandles, but suggests hacking subprocess.py, which
  we were extremely reluctant to do for production software.
  
  We also found:

Re: [PyInstaller] Python, Windows and no console environments

2017-03-16 Thread Jones, Bryan 
This link might be relevant --
https://github.com/pyinstaller/pyinstaller/wiki/Recipe-subprocess

Have you tried those suggestions?

On Thu, Mar 16, 2017 at 10:47 AM, Coyot Linden (Glenn Glazer) <
co...@lindenlab.com> wrote:

> We discovered that code which ran perfectly correctly by executing the
> scripts in the POSIX environment or via python on the Windows command
> prompt would fail when compiled using the -w flag to PyInstaller. This flag
> prevents the application from launching a console window when the
> application starts, which we clearly did not want with our client. The
> problem occurs when a caller executes Python's subprocess and the caller
> tries to implicitly or explictly access stderr or stdin on Windows.
>
> Because this originally occurred in our code with a caller of an imported
> module our test code used that mode.  We believe it can be reproduced
> without the caller.
>
> We also believe that this error is a deep down result in the pythonw
> implementation on Windows and PyInstaller just makes it more obvious.  Some
> trials suggest that pythonw produces the same failure cases, albeit with
> somewhat different output.
>
> To the PyInstaller team: we found (and is reproducible with the code in
> the appendices below) that even with -w, a console window flashes for a
> tiny fraction of a second.  Is there any way to eliminate that completely?
>
> -
>
> So beginning with code that fails that shows the example, we have:
>
> Sample problematic caller code:
>
> #!/usr/bin/env python
>
> import cgitb
> import os.path
> import subwrapper
> import sys
>
> cwd = os.path.dirname(os.path.realpath(str(sys.executable)))
> cgitb.enable(logdir=cwd, format='text')
>
> print subwrapper.getMachineID()
>
> Sample problematic imported module code:
>
> #!/usr/bin/env python
>
> import subprocess
>
> def getMachineID():
>return subprocess.check_output(['wmic','csproduct','get','UUID'])
>
>  Sample output under python:
>
> >python caller.py
> UUID
> D8F59000-4F39---
>
> Sample output when compiled with the -y --clean --onefile flags:
>
> >caller.exe
> UUID
> D8F59000-4F39---
>
> Sample output when compiled with the -y -w --clean --onefile flags:
>
> No output.  Failure to execute script window appears (the name depends on
> the script name):
>
>
>
> Note that this error message is specific to PyInstaller, it comes from
> https://github.com/pyinstaller/pyinstaller/blob/
> a70b20e4de6a6817987d28ca9f3201c8105fd858/bootloader/src/pyi_launch.c#L411
> .
>
> As noted above, we ran the toy scripts under cgitb tracing to obtain
> detailed call stack information which does not normally appear when that
> Window appears.  Full cgitb output is below, but the important part is:
>
> Traceback (most recent call last):
>   File "caller.py", line 11, in 
>   File "subwrapper.py", line 6, in getMachineID
>   File "subprocess.py", line 566, in check_output
>   File "subprocess.py", line 702, in __init__
>   File "subprocess.py", line 823, in _get_handles
> WindowsError: [Error 6] The handle is invalid
>
> Researching that error message led us to:
>
> https://github.com/incuna/django-wkhtmltopdf/issues/91#
> issuecomment-179080434
>
> which points at the problem being related to the passing of filehandles,
> but suggests hacking subprocess.py, which we were extremely reluctant to do
> for production software.
>
> We also found:
>
> http://stackoverflow.com/questions/337870/python-
> subprocess-call-fails-when-using-pythonw-exe
>
> which states
>
> *"sys.stdin and sys.stdout handles are invalid because pythonw does not
> provide console support as it runs as a deamon, so default arguments of
> subprocess.call() are failing.*
>
> *Deamon (sic) programs close stdin/stdout/stderr purposedly and use
> logging instead, so that you have to manage this yourself: I would suggest
> to use subprocess.PIPE."*
>
> The last comment at the end of that StackOverflow indicates that people
> have been running into this problem with pythonw and PyInstaller since 2014.
>
> Putting these things together, we realized that -w is destroying the
> stderr filehandle. We now do subprocess calls this way:
>
> with open(os.path.join(cwd,'output'),'a') as bar:
>with open(os.devnull) as nullin:
>try:
>foo = subprocess.check_output(['
> wmic','csproduct','get','UUID'], stdout=subprocess.PIPE,
> stderr=subprocess.PIPE, stdin=nullin)
>print >>bar, foo
>
> which is to say that we never, ever use stdin or stderr on Windows for
> anything, explicitly OR implicitly through default options.  E.g., passing
> None to check_output() for a handle or not specifying a handle causes it to
> inherit from the parent and there is nothing to inherit and hence the
> invalid handle error message.  No print statements, either.  All debugging
> must go to logs.
>
> Best,
>
> coyot
>
> Appendix A - Correct Version of caller.py
>
> #!/usr/bin/env python
>
> import cgitb
>