[Pythonmac-SIG] What is the future of Python on OSX?

[Jack Jansen]

On vrijdag, september 6, 2002, at 10:23 , Bugbee, Larry wrote:

> My 2 cents...
>
> As developers for developers we can do pretty much what we want for the
> installation, but if we expect mere mortals to run the stuff we 
> develop, we
> need to have an installation that is simple to understand, easy 
> to use, and
> complete.  The typical user will not be in a position to 
> understand all the
> dependencies, or go through any screwy procedures to get 
> something to work.

Fully agreed.

I've just finished handling the core part of creating a 
framework installer for Python.
People interested in trying this at home should update their cvs 
trees and check out
Mac/OSX/README, it now has instructions on creating a binary 
installer for a MacOSX framework-based Python. Thanks go to Dinu 
Gherman for his buildpkg script (which is now included in 
Mac/scripts).

> I therefore submit the OSX Python installation of GUIs should:
>
>   - have no dependencies.  A single installation should
>     install all that is required beyond that provided by
>     the vendor.  (I know this will be point of contention,
>     but the end user really doesn't care about our problems.)

I think that we can't do this, practically. For OSX Python GUI 
development there are currently four options: Carbon, Cocoa, 
Tkinter and wxWindows. Of these only the first one (which is 
also arguably the worst choice) is included with the core 
distribution (as created with the script above) because the IDE 
needs it.

But: I think we can do something that is almost as good, if we 
create a simple way by which an end user can install add-on 
packages for Python.
I've dropped this idea here before, but noone reacted, so here 
goes again.

We create a bit of software called the Python Install Manager. 
This should probably be a part of the IDE (or at least be 
accessible easily through the IDE, with a GUI and such). It goes 
to a specific location on the net where it retrieves a current 
database of installable Python extension packages. It then 
presents the user with this list, and for each package also 
shows whether it's currently installed, not installed or 
installed but outdated (i.e. the database has a newer version 
than the user has). The user can then easily install or remove 
packages at the click of a button.

The packages in the database consist of a Python script to 
determine whether you have it installed at the moment (and 
determine the version number) and a script to do the 
installation of a current version and a list of dependencies.

For a simple pure-python package the scripts would be simple: 
the test script would be an import of the package to determine 
existence and a version check. The install script would be a 
download plus a distutils-based install.

For Python packages with extension modules the install script 
should grab a binary distribution (also distutils based).

For external packages (i.e. the AquaTk package needed by a 
Tkinter package) the install script can fire up standard MacOS 
tools to install the package.

For really complicated things the install script should open an 
instructions page in the users' webbrowser.

The amount of code needed for all this isn't all that much. The 
real work is in two things:
- deciding on a database format that is rich enough, but also 
small enough to actually be implementable in the 2.3 timeframe 
(a few months, I guess)
- finding someone who will take responsibility of keeping the 
database plus the underlying installers up to date.
>
>   - install the same GUI interfaces included in the
>     standard installations of another platforms.  GUI
>     apps should run on OSX just as they would on Linux
>     or Windows.  For now this includes Tkinter.

But unfortunately AquaTk installation, on which Tkinter depends, 
is non-trivial
at the moment:-(
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -