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

[Kevin Ollivier]

On Friday, September 6, 2002, at 06:30  PM, Jack Jansen wrote:

>
> 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.

I've been thinking about that myself. The database could actually be run 
off the web and output an XML file which the Python Install Manager 
client software would read. Making it web-based would enable the 
developers themselves to go online and add their package information to 
the repository. For the more complicated stuff, we could let the 
developer specify "pre" and "post" install  scripts for dependencies 
without bloating the database format. We could also work on getting it 
hosted by the PSF on python.org, that way ensuring that it will be 
maintained. And the GUI for it could be written in wxPython, forcing it 
to be included in the base distribution... hehehe... =)

I even thought about a name for the web-based database... Get ready... 
the "Searchable Python Archive of Modules". Yup. SPAM. ;-) What do you 
think?

Thanks,

Kevin

>>
>>   - 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 -
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>