[Distutils] Installing scripts

[Mark W. Alexander]

On Thu, Jun 10, 2004 at 04:27:29PM -0400, Fred L. Drake, Jr. wrote:
> On Thursday 10 June 2004 04:06 pm, Tim Peters wrote:
>  > "scripts" in the sense we're using here are Python files, and in Windows
>  > they're only useful from "a DOS box".  It's not useful to double-click on
>  > them, it's not useful to have Start menu entries(*) for them, and it would
> 
> Agreed.

At first I did to...

>  > be hostile to hide them in a hard-to-spell-in-a-DOS-box directory (like
>  > anywhere under the space-ridden "Program Files").
> 
> What's a little hostility among Windows users?  They're used to it.  :-)
> 
> Seriously, though, I agree.  "Program Files" is hostile in general for anyone 
> using a command line.

But then I read this and considered that sometimes script==application,
while other times script==background_utility. I would think Windows users
would like "applications" to appear in the start menu, while "behind the
scenes" utility scripts live quietly and invisibly elsewhere. I don't
really see "scripts in a DOS box" as a typical Windows use of Python
stuff. That may be my bias as my Python on Windows experience is pretty
much limited to PySol ;)

Maybe we need to consider some kind of "menu" support module that
conforms to freedesktop.org menu standards (GNOME & KDE are jointly
working on this and I suspect, or at least hope, Linux distros will
support it as well.) on *nix targets and "Start Menu" on 'doze. I would
suppose that the application installer would have to somehow register
where the utility scripts live (presumably the install directory or a
subdir there-of).

I'm fairly certain this is a non-trivial excercise, and should be dealt
with independent from the file extension issue.

>  > For cross-platform *development*, all Python files should have a
>  > .py extension.  On Windows the extension drives editors and
>  > printers too (not just the "open" action in a DOS box window).
> 
> I'm actually pretty OK with this.  It's slightly distasteful, but
> survivable.

I think the word you're searching for is "practical" <g>. Whatever the
"Windows experience" might be, Distutils has to live down to it.

>  > (*) The only thing useful to have in the Start menu is a program
>  > that supplies its own GUI, or a program that has no UI.  On
>  > Windows, that's what the .pyw extension is for (brings up Python
>  > without "a DOS box", so there's no UI at all unless the script
>  > supplies its own UI; for example, IDLE supplies its own UI, via
>  > Tk).

I'm not sure I agree. If a developer wants to distribute a Python in a
DOS box for Windows, Distutils certainly shouldn't prevent it. A simple,
scriptable Python text only IRC client might be popular (but this is
from a guy who has a Cygwin rxvt under ssh-agent launched in his
rarely-booted XP autostart ;)

> This brings up a related question:  If a distribution provides scripts
> that end with .pyw, should they be omitted from the
> builld/installation on non-Windows platforms (possibly with a warning
> to the user)?  Do we want a way to tell distutils about
> platform-specific scripts so they don't get installed on platforms to
> which they don't apply?

Too lazy to go look at the PEP, but isn't "supported platforms" one of
the metadata fields? If not specified, it should be "any" and if .pyw's
exist it should include (maybe default to?) win32. If something has
.pyw's AND supports other platforms as well, then not explicitly
specifying the supported platform information (which could _still_ be
"any") should be an error.  How other platform support is implemented in
such a case should be up to the author. Trying to make Distutils smart
enough to second-guess the author's intent, or the package's
capabilities, would be problematic at best.

OTOH, a boolean GUI tag for scripts might be beneficial for
cross-platform menu integration, so ... I'll stand firm on the "maybe"
side of the question.

mwa
-- 
Mark W. Alexander
slash at dotnetslash.net

The contents of this message authored by Mark W. Alexander are
released under the Creative Commons Attribution-NonCommercial license.
Copyright of quoted materials are retained by the original author(s).

http://creativecommons.org/licenses/by-nc/1.0/