Skip to content

Conversation

@sergiocorreia
Copy link

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

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!

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
@sergiocorreia
Copy link
Author

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 pushed a commit that referenced this pull request Jun 8, 2015
	- addresses issue raised in: #9
@msprev
Copy link
Owner

msprev commented Jun 8, 2015

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
Copy link
Owner

msprev commented Jun 8, 2015

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
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

msprev commented Jun 8, 2015

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
Copy link
Author

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

@msprev
Copy link
Owner

msprev commented Jun 8, 2015

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

@msprev
Copy link
Owner

msprev commented Aug 13, 2015

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?

@msprev msprev closed this Sep 1, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants