-
Notifications
You must be signed in to change notification settings - Fork 13
(Windows) Fix bug when calling .py files #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Windows cannot directly call .py files because they are not executable (they are instead intercepted and called with python.exe) See: http://stackoverflow.com/questions/25651990/oserror-winerror-193-1-is-not-a-valid-win32-application Solution: Attach the python executable to the command
|
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. |
- addresses issue raised in: #9
|
Thanks very much for this PR. panzer is untested on Windows, so anything related to it is very welcome. I've just pushed my 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? |
|
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: |
|
This is indeed a python-only fix. 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.. |
|
I think |
|
I agree that I'd like to avoid this if possible. The 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 |
|
I'll check; might take a few days though just to be sure :) |
|
Thanks! Let me know if the dot-slash trick solves the problem! |
|
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? |
Windows cannot directly call .py files because they are not executable
http://stackoverflow.com/questions/25651990/oserror-winerror-193-1-is-not-a-valid-win32-application
subprocess.PopenAlso, 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!