[Pythonmac-SIG] Let's do it completely different!

[Alexandre Parenteau]

Hi,

Let me point out something, and I don't really answer that to bill, but in
relation to the thread : we don't have to deal or worry with Apple's
installation of python. Python is not a critical, or even Apple component
for Apple. Whatever we'll find useful, they'll probably use.

So augmenting the so called "Apple installation" has no appeal for me. I
would rather have *one* installation, which can extend beyond the command
line. And Apple will probably use it.

I was quite happy with the current direction, so I fail to understand why
Frameworks are not good anymore (independently of really needing it for
embedding). Keeping the nice integration to the mac is the critical point, I
would argue, and whether we use frameworks or dylib is not relevant to me.
But whatever replaces the current scheme has to be better for applets, IDE
and other mac specific goodies in my mind.

Thanks,
Alex.

> 
> On Friday, October 18, 2002, at 02:09  PM, Jack Jansen wrote:
> 
>> Hello folks,
>> after arguing myself blue in the face for the last year and finally
>> convincing the majority here that Frameworks Are A Good Thing
> 
> I wasn't convinced, I deferred.;-)
> 
>>  I feel the time has come to reverse my position. Or, at least, I'm
>> not as convinced as I was. And I think I can see advantages with going
>> non-framework. Or at least keeping both options open. I don't know,
>> just read on and comment, please.
>> 
>> The framework option has the following advantages:
>> 1. Easy installation and de-installation, everything lives in
>> /Library/Frameworks/Python.framework or /Applications/Python.
>> 2. Allows us to do applets (such as the IDE) without duplicating big
>> binaries.
>> 3. Allows us to do "pythonw" and "PythonLauncher": running Python
>> scripts with a GUI that appear normally in the dock, etc.
>> 4. Allows us to share a single Python engine between Python and all
>> embedders of Python (such as the Python OSA component).
>> 
>> I think we can do an architecture without frameworks that will allow
>> us to do all of these except 4.
> 
> Embedders are hosed with the Apple installation from the start. There's
> no libpython.a, let alone a libpython.dylib. We should provide a
> libpython.dylib for the present, and make it part of the default
> installation in 2.3. Then all the problems with big executables go
> away. Embedders are happy. And we won't have to continue providing it
> once it works its way through channels and Apple starts distributing it
> with the OS. More importantly, we don't have to redo the applet
> architecture (either now or to change it back to take advantage of
> shared libraries in the future.)
> 
>> To start we build on the existing Apple-installed /usr/bin/python (or
>> any other pre-installed Python, from fink or whereever). So, our
>> MacPython-OSX installer does not necessarily include Python itself.
> 
> But it should include the library that went missing somewhere along the
> way. Again let me stress that that is version specific, and it
> addresses a deficiency in the current Apple installation.
> 
>>  This gives two immediate advantages: we can stuff everything into
>> /Applications/Python (making installation and de-installation even
>> easier) and we can do a MacPython-OSX distribution without waiting for
>> Python 2.3. This would give people like Walt a decent way to explore
>> Python through the IDE, without having to learn about the unix command
>> line.
> 
> You can still do that with everything but the library. And that's only
> in 2.2. After that, everything is once again in /Applications/Python
> (or in Library/Frameworks).
> 
>> Applets we do with a two-stage approach. First, each applet will have
>> a symlink Contents/MacOS/python pointing to /usr/bin/python. Second,
>> the main binary of the applet .app bundle (CFBundleExecutable) will be
>> Contents/MacOS/runapplet. This is a small program that finds the
>> applet file and calls ..../Contents/MacOS/Python with the applet code
>> as argv[1]. The rest of appletrunners args are also passed through.
>> This is the bit that needs to be tested, but I think that if we do
>> things this way the final executable will have an argv[0] that points
>> into the .app bundle, and thereby the window services initialization
>> code will work.
> 
> This would probably work, but is unnecessary with a shared library.
> 
>> "pythonw" is now easy: we can just use the Contents/MacOS/python from
>> any applet. We could use the PythonIDE, but as that would give every
>> running Python GUI script the IDE icon in the dock it may be nicer to
>> put an empty applet PythonW.app into
>> /Applications/Python/PythonIDE.app/Contents/Resources.
>> 
>> PythonLauncher basically doesn't change.
>> 
>> A last issue is where we put our nifty Mac modules (that are now in
>> Mac/Lib inside the framework, plus _waste.so and anything else that we
>> need and that's missing from the 2.2 that Apple distributes). One
>> option would be to install them into
>> /usr/lib/python2.2/Lib/site-packages. A possibly nicer option would be
>> to also put them somewhere in Contents/Resources of the IDE, and put a
>> MacPython.pth file into site-packages.
> 
> I agree with the .pth file in site packages, but worry about putting
> all the MacPython stuff in PythonIDE. What if someone trashes it? ("I
> don't want to develop Python apps, so I don't need this big fat
> application...") All the MacPython dependent stuff is suddenly broken.
> 
> With a shared library, you can dress the whole thing up as a framework
> and put the Mac specific stuff there. Once Apple starts distributing
> the shared library, EVERYTHING gets installed in "user friendly
> places", i.e. in /Library/Frameworks or /Applications/Python. In the
> meanwhile, we've got a left-over shared library in /usr/lib/python2.2.
> 
> OTOH, you can delete any app without trashing any other app, since
> everything we install, or subsequently create, links against the shared
> library. And trashing the framework breaks them all, as expected.
> 
> --
> bill
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>