On Tue, Aug 13, 2013 at 12:33 PM, Paul Moore <p.f.moore@gmail.com> wrote:
This works, but is an ugly, fragile workaround. It's *not* a huge problem, it's just how executables work on Windows, and all installers have to deal with this dance (it's why a lot of things need a reboot to complete installation - the "delete on next reboot" API). But it's not *nice*.
I would never use exe wrappers for my own personal scripts - I *always* write them as .py files and rely on PATHEXT. I only use exe wrappers for commands installed as part of a Python package (pip.exe, nosetests.exe, etc). That says something about how friendly they are as a general tool.
In an ironic reversal, I use them for any command I plan to use frequently. In other words, if I use it often enough to care about how easy it is to use, I take the trouble to wrap it in a project and then use setup.py develop to create the script wrappers. From then on, I can edit the *source* scripts, and the wrappers run the right thing. (I don't edit the -script.py's directly, since they're not where the real code is.)
On another point you mention, Cygwin Python should be using Unix-style shell script wrappers, not Windows-style exes, surely? The whole point of Cygwin is that it emulates Unix, after all... So I don't see that as an argument either way.
I said I'm using *Windows* Python from the Cygwin shell. I often test my projects with Cygwin Python, to ensure coverage of Unixisms, but I only write dedicated Cygwin Python scripts if I need to use Cygwin paths or APIs, which is relatively infrequent. In any case, the use of .exe means that my invocation patterns are unchanged between commands I've implemented in Cygwin Python vs. Windows Python. If the Windows Python versions used a different extension, then I'd have to remember whether which language a specific command was written in in order to invoke it.