[Pythonmac-SIG] What is the future of Python on OSX?
Jack Jansen
Jack.Jansen@oratrix.com
Sat, 7 Sep 2002 00:30:57 +0200
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 -