[Pythonmac-SIG] Python.framework under OS X

[Tim Lahey]

On Monday, July 23, 2001, at 04:59 AM, Jack Jansen wrote:

>
> Ok, time for some detailed discussion.
>
>> 1. Build the core python distribution as a framework to be placed
>> in /Library/Frameworks. Allows for easy installation and
>> accessible for all Applications.
>
> One problem here is that /Library/Frameworks/Python will look different 
> from
> what unix-pythoneers are used to. It'll be similar, but different. I'd 
> like to
> know whether its possible to but a "normal" python installation in here 
> (say,
> in /Library/Frameworks/Python.framework/python) and put the framework
> mumbojumbo in symlinks. Hmm, yes, the existing frameworks already do 
> that, so
> symlinking should be fine.

As for the structure of the framework, I'm more than willing to defer to 
others. The
main reason I see for a framework is the ease of installation and 
inclusion with
an application. I'd rather not hide things in /usr/local/lib/pythonx.x, 
it doesn't
really fit with the general OS X philosophy.

>
>> 2. Set the PYTHONPATH to search the ~/Library/Python then
>> /Library/Python for additional modules. Basically, they would
>> act as local and global site-packages directories.
>
> I think I'd prefer the global site-packages to live in 
> Lib/site-packages in
> /Library/Framework/Python.framework/ just so we're not accused of 
> changing
> things without reason (by the rest of the unix-pythoneers). The
> ~/Library/Python idea I like.

The only problem I have with this is that it means that the contents of 
the framework
will be exposed and edited by the users.
>
>> 4. Create a PythonInterpreter View Interface Builder Pallet so
>> applications can embed the interpreter inside the application
>> along with a place for user interaction.
>
> Oops, buzzword overload. I know the various words, but the stringing 
> together
> doesn't result in added meaning. Could you expand on this a bit?

Basically, I want a IB widget that one can add to their application that 
provides
an interpreter view. This would allow one to customise the relative to 
the application,
some might want the interpreter in a separate window, others at the 
bottom of a
main window.

> I think we can do it so that people could do both, but initially I think
> Carbon is the way to go. I have most of the MacPython toolbox modules 
> ported
> (at least: they compile and import), I'm working on the few basic 
> necesseties
> we need to put Carbon and BSD together (FSRefs, CFString and friends) 
> and on
> replacements for things we're going to lose (MLTE to replace Waste; 
> that is,
> unless someone wants to invest some time into getting Waste to run under
> Mach-O Carbon. This would be *very* welcome as lack of Waste is the 
> main thing
> that stops us from starting on IDE).

The way I see things is that people will have two ways of building a UI 
for their
application:

1. In python, using a wrapper around Carbon calls.
2. In Cocoa/Carbon, with python embedded in the application, but not 
creating
the UI.

I think both have their place. One way of doing an IDE for OS X python 
would be
the second.

>
>> 6. Being porting some of the other python modules to the new
>> UI. I'm thinking of various ones such as PIL and PyOpenGL.
>
> PIL should be trivial, PyOpenGL also not too difficult.

PIL shouldn't be too bad using either method of making a UI, PyOpenGL 
wouldn't
be difficult to use with python embedded in a Cocoa app, I'm not sure 
about through
Carbon.

>
> Most of what I've done so far is in the repository already, the one 
> exception
> being the setup.py file (which will build all the toolbox modules and 
> such). I
> can mail it to people who want to play with this stuff, and I'll also 
> try and
> think of a way to put it into the repository without overmuch bothering 
> people
> who use OSX as a unix box.

I'll take a stab at things, although I generally use OS X as a UNIX with 
a nice GUI.

Cheers,

Tim Lahey
tjlahey@cgl.uwaterloo.ca