(Windows) Fix bug when calling .py files

[sergiocorreia]

Windows cannot directly call .py files because they are not executable

• Discussion: http://stackoverflow.com/questions/25651990/oserror-winerror-193-1-is-not-a-valid-win32-application
• Solution: Attach the python executable to the command when running subprocess.Popen

Also, I'm not very good with Github, but we may be missing a .gitignore file. When rebuiliding I got a few folders (build, pychache, panzer.egg-info) that my github client was trying to attach to the PR.

Thanks!

[sergiocorreia]

I added an additional fix when calling filters. If there were more than two of these I would propose a quick function but with two it's probably not worth it.

[msprev]

Thanks very much for this PR. panzer is untested on Windows, so anything related to it is very welcome.

I've just pushed my .gitignore file to the head of the master. It should address the issue that you raise.

Just one question before merging. I'd like something that is agnostic about the kind of script or filter being run (python, Haskell, perl, ruby, etc). This is a fix only for python. Do similar issues arise with other scripts?

[msprev]

How about adding information explicitly about the executable (if needed) in the metadata? This would allow the user to choose whichever executable is revelant for the script. Something like:

preflight:
    - run: my_script.py
      args: "`--flag`"
      executable:
          windows: python.exe

[sergiocorreia]

This is indeed a python-only fix. Sadly, each language has a different interpreter so there is no general solution AFAIK. For instance, even with python there are several alternatives (such as running the py.exe wrapper on the %WIN% folder, or the python.exe on C:/python34/ , and so on). It's even trickier if someone has py2 plugins (which they may like to run with a different interpreter.

With filters, I found that an easy fix would be to call "./scriptname.py" (so the dot+dash are required). With preflight/cleanup/etc, I'm not really sure..

[sergiocorreia]

I think executable is an alternative, but it still pains me that we are adding complexity both to the style files and to panzer... (maybe you can leave an issue open until a better soln is found)

[msprev]

I agree that I'd like to avoid this if possible. The executable field would be optional and would be added only if needed (as in Windows).

I'd prefer a more lightweight solution. Could you let me know if the dot+slash trick addresses the issue completely on Windows for script and filters? If so, I will update the documentation to reflect this. If not, then I will implement something along the lines of the executable field.

[sergiocorreia]

I'll check; might take a few days though just to be sure :) Best! Sergio

[msprev]

Thanks! Let me know if the dot-slash trick solves the problem!

[msprev]

Is there any update on this? If the dot-slash trick works to make it behave on Windows, then I'll update the documentation and close this PR?