[Distutils] How to handle launcher script importability?

[PJ Eby]

On Tue, Aug 13, 2013 at 12:33 PM, Paul Moore <p.f.moore at 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.