Re: [Pyobjc-dev] pyobjc on 2.2.1 & non-framework builds

[Ronald O. <ous...@ci...>]

On Tuesday, Sep 24, 2002, at 19:48 Europe/Amsterdam, Bill Bumgarner 
wrote:

>
> In all, it solves a different problem than the problem presented by 
> the goal of creating standalone fully Cocoa compliant applications.  
> Namely, PythonLauncher is much more about invoking a particular script 
> and much less about distributing a standalone ".app" that a user can 
> simply double-click to use.

Could you please rename your PythonLauncher, two applications with the 
same name is pretty confusing. To illustrate this: The 'PythonLauncher' 
you mention above is probably Jack's version, not yours but I'm not 
entirely sure...

Just to make things clear: Is your PythonLauncher meant to be a binary 
that can be dropped in a '.app' directory to create a python-based 
application?
>
>>
>>>
>>> It also requires a framework build of python.  This is completely 
>>> unnecessary and incurs an arbitrary limitation [user has to have 
>>> Python.framework around as opposed to using the standard 
>>> out-of-the-box Python included with 10.2].
>>
>> Is the framework really necessary or is it only required because of 
>> the current build procedure?
>
> The framework isn't necessary at all.   Everything pyobjc related 
> works fine with the "out of the box" install included with OS X 10.2.

I was refering to your remark about (Jack's) PythonLauncher requiring a 
framework python, but given the completely different goals of yours and 
Jack's PythonLauncher that is not really relevant.

>
>>
>> BTW. I'd prefer to have a framework install of python as the standard 
>> python sometime in the future. Maybe in MacOSX 10.4........
>
> I would rather see Python remain as open and cross platform compatible 
> as possible.  In that context, a framework (or bundle) might be an 
> appropriate means of encapsulating resources specific to the Macintosh 
> extension modules.  I.e. the mac specific (OS X, really) resources 
> would be shoved into PyMac.framework down in site-packages (assuming 
> the macintosh support were to remain as a module).
>
>   However, encapsulating all of python into a framework doesn't really 
> add anything to the environment in terms of features and definitely 
> makes for a weird twist when using the Mac platform.

This is probably something that should be discussed on the 
Python-on-Mac SIG, but what the heck...

I definitely do not like a partial framework (the unix install 
containing a PyMac.framework for Mac specific stuff). That would be 
both confusing and reduce cross-platform compatibility (e.g. how should 
distutils cope with that?).

Like you said, the framework install doesn't really add new features. 
However, I also feel that it doesn't hamper cross-platform 
compatibility and openess. If you replace /usr/bin/python by a symlink 
to the python inside a framework install the resulting situation is 
completely compatible with the current situation.

The reasons I like the framework approach are twofold. First of all 
frameworks are the method Apple is pushing for publishing library-type 
stuff (and I like to think of the python interpreter as a complicated 
type of dynamic loader :-)). But more importantly, a framework install 
makes it more clear that Python is not just tool for 'unix weenies' but 
something you can use for real work.

BTW. I'm a Unix weenie myself and most (Python) code I write at the 
moment has to do with either command-line scripts or webbased stuff. 
The framework install of Python I have at my machine is perfectly 
useable for this.

Back to making Python the best development tool on MacOS X,

	Ronald

P.S. Don't let this keep you from improving PyObjC for users of the 
Apple-distributed Python ;-) ;-)