[Distutils] Installing scripts

[Tim Peters]

[Fred L. Drake, Jr.]
...
> The issue is that the expectations of end-users on Unix and Windows
> differ substantially.  Unix users generally expect that scripts will not
> have extensions and don't need to have a specific interpreter named on
> the command line (since that's what sh-bang lines are for).  Windows
> users really expect an icon to click on, and are massively confused by
> extension-less files.

Nobody expects to click on a .py file icon on Windows (unless they've
changed the default action for .py files to something other than the Python
Windows installer establishes).  Forget clicking on icons.  Unix has a #!
line to establish the program used to execute a script, but the Windows
gimmicks are much richer than just that:  any number of distinct "actions"
can be associated with a file extension, like what to do to "open" the file,
what to do to "print" the file, what to do to "edit" the file, which custom
entries to display in the right-click context menu, and so on.

An ideal system would perhaps associate metadata with files, instead of
associating via the file extension (yuck!), or actually burying it in the
visible guts of the file (double yuck!  only a terminally naïve Unixhead
could think that's a *good* design <wink>).  Tough noogies.  We're stuck
with #! lines on Unixish boxes, and stuck with file extensions on Windows.
*Every* file on Windows a user can see should have an extension, BTW.  It's
impossible to associate actions with "the empty extension", and associating
actions with files is extremely useful on Windows for many reasons
(including for what #! does on Unixish boxes, but for more than just that).

> Windows encourages this confusion.

That's like saying Linux encourages confusion about how to run a script
without a #! line.  Actions are associated with extensions on Windows, and
that's all there is to it.

> Adding a .py extension to Python scripts on Windows allows the user
> to at least not have to add the path to the Python interpreter on the
> command line if they want to run the script using the default Python
> installation (meaning "the one registered to handle the .py extension").

That's the "open" action associated with .py on Windows.  PythonWin also
sets the .py "edit" action to bring up the PythonWin editor, and the Python
Windows installer sets a custom "Edit with IDLE" action for .py files (which
appears if you right-click a .py file).  The installer also associates cute
snake icons with .py; icons visually distinguish file types in the Windows
Explorer GUI.

> This can be handled by passing a different value to the current script=
> keyword argument to distutils.core.setup() based on os.name, and having
> versions of scripts for Windows and Unix.  This seems tedious at best,
> but works, and allows flexibility in implementing the scripts differently
> for the two platforms.
>
> I'm interested in hearing about how others are handling this issue for
> software that's intended to work on both Unix and Windows.  Is there a
> better approach?  I'd love to find a better way to support end-user
> expectations across platforms, especially if it could involve less magic
> in the setup.py script.

At least stick a .txt extension on text files users may want to read.  Does
it also offend delicate non-Windows sensibilities, e.g., to see README.txt
instead of README?  If it does, the issue is broader than just .py scripts.
There's nothing more irritating on Windows than to double-click on a README
file and then have to slog through a list of 500 registered "open" actions
to pick the "bring up my favorite text editor" action.  Well, OK, maybe
having to reboot every hour is a *little* more irritating than that <wink>.