Python 2.4 killing commercial Windows Python development ?

[Dave Brueck]

Terry Reedy wrote:
> I guess I don't understand some people's determination to not have users 
> install fully useable Python on their Windows machines.
[snip]
> To put it another way, needing a Python interpreter to run .py files is no 
> different from, for instance, needing a movie player to run .mpg files, and 
> all Windows users are or need to become familiar with that general concept.
> 
> Also, I think it a bit 'anti-social' to hide usage of Python.  If all 
> Python Windows programs ran with a normal, communally installed Python, 
> then users would gradually get the idea that having Python installed is 
> much like having Shockwave and other utility platforms installed, and that 
> is is part of a 'fully loaded' Windows system to have a .py player 
> installed.
> 
> If there is something about the default install of Python on Windows that 
> makes it less desireable or less easy than other platforms, then maybe that 
> can be fixed.  To make installation easier, maybe someone could write a 
> small .exe that could be frozen with scripts or run with installers and 
> that would detect the presence/absence of the needed Python version and 
> offer an auto download and install if needed.

I mostly agree with the sentiment, but it does break down a little in practice. 
At least currently it does - like you said, this is fixable, but nobody has 
signed up to fix it yet.

The main thing that's needed is a zero-input Python distribution - a Python 
runtime, if you will - that (1) gets installed to a "good" place (2) does so 
without asking the user to do anything, (3) can coexist with different versions 
of the runtime, and (4) is easily detectable by applications wanting to use it.

One other minor component is a small launcher executable, because on Windows 
it's non-trivial to find out which "python.exe" in the task manager is running 
which Python script. Anyway, each app would have a small launcher that 
bootstraps the actual Python script[1]. (Or, if there's some way to trick the 
task manager into displaying something besides "python.exe", that'd work too)

In order to "fit" into the expectations of a typical Windows user, an 
application installer needs the ability to check for the presence of a 
particular version of the Python runtime, and then install it if it's not 
present, and do so without asking the user to do anything.

With that much in place, a lot of the need for freezing Python apps goes away 
(definitely not all of it, but a lot of it). Here's stuff that still needs to be 
considered though:

1) A way for apps to specify their compatibility with different versions of the 
runtime - "I work with pyrt2.3.3 through 2.4.1"

2) A way for apps to register their dependency on that runtime, so that if the 
user uninstalls it, there is at least an indication of what programs might break.

3) (this is a nice-to-have, but not 100% required) A way to download additional 
libraries once and use them for multiple programs, e.g. the installer could see 
if ctypes is present, and if not, go get it. Later programs would take advantage 
of it already being installed. Like I said, not a 100% requirement, and some of 
the ongoing work with code CPAN-like code repositories would shoehorn into this.

4) The security implications, e.g. an innocent app installs pywin32 and enables 
Python client-side scripting in Internet Explorer, and later this is used as a 
big door for malicious users to use.

Most of these tasks don't require a lot of work; indeed this has been on my "one 
of these days" lists for awhile. The main reasons it hasn't been done yet:

1) The code freezing tools like py2exe are *very* good and convenient 
(especially since loading code from zip archives was added - even if you include 
all of Python, it's only a few files on disk, and now they're all in the same 
directory)

2) Storage space and download speeds continue to increase at a rate much faster 
than the rate at which the size of Python is growing - a download of a few MB 
isn't too bad these days, who cares if your app takes 4MB on disk, and so what 
if it doesn't fit on a floppy, for example.

3) As soon as you get started on such a project, almost immediately you will be 
overwhelmed with a desire to create a CPAN-like system while you're at it, at 
which point your project's status will shift from "making good progress!" to "in 
quagmire, developers MIA". :)

-Dave

[1] I built a hacky one of these launcher exe's for one project, and it was 
fairly reusable for apps in the same vein. Basically, the exe would would look 
to see what its name was, and then load a Python module of the same name. So if 
you have MyGame.py, you'd just take the generic launcher.exe, copy it to the 
same directory as your .py files, and rename it to MyGame.exe. On launch, it'd 
load the interpreter, load MyGame.py, and pass it the command-line args.