Re: [Pyobjc-dev] pyobjc on 2.2.1 & non-framework builds
Brought to you by:
ronaldoussoren
From: Bill B. <bb...@co...> - 2002-09-25 19:31:12
|
On Wednesday, September 25, 2002, at 01:51 PM, Ronald Oussoren wrote: > 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... Oh, I suppose -- I mean, my PythonLauncher was actually a quickie hack posted to python-mac to answer some questions about how to write a PythonLauncher type thing. I even cc'd Jack on the original... But, he beat me into the repository, so the name is his. :-) The above referred to Jack's app. (In all seriousness, yes-- the name should and will be changed if I get around to writing a replacement for the existing [Jack's] PythonLauncher). > 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? Nope -- that is a completely different app/problem. More info later today. >>> 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... We can go there once we have hashed through it a bit here... > 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. If it doesn't add any features, then why add all of the administrative/maintenance overhead to the core python project that is necessary to support it? Looking at the piles and piles of patches required in configure, the various makefiles, and an entire subdirectory full of gunk that is special cased into the framework build, it seems that the framework build is already hampering cross-platform compatibility in that it requires so much extra effort to make python work on the Mac platform [assuming a framework build is a part of supporting the Mac platform]. Anything that unnecessarily makes the Macintosh support behave differently than, say, bsd/sun/linux hampers cross platform compatibility. > > 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. Apple pushes framework based encapsulation of things that are libraries for reusable code specific to the platform, not for reusable/libary code that is made available across many platforms. Looking at the system (and Darwin), the only exception is the readline framework. Looking /usr/lib/ reveals that Apple is very much pushing for a build model for portable code -- libz, termcap, ruby, perl, python, tcl, crypto, pthreads, etc... -- that requires as few changes as possible between OS X/Darwin and any other Unix derived platform. IMO, this is a wise decision -- it reduces the amount of maintenance necessary on the part of Apple and third party developers to achieve continued first class support for these tools on the platform. Whether Python is in a framework or as a regular "command line" tool will do little to attract or deter non "unix weenies" from using it. We will be able to attract many more developers by supporting and providing examples for doing Python development in PBX using the out-of-the-box python on OS X. Certainly, having a Python IDE and the ability to run individual scripts from, say, the Finder will help, but having to rebuild/reinstall Python to gain access to that capability will deter many. Given the rather crufty implementation of said solutions-- Carbon is legacy and at a completely different granularity than Python or Cooca-- quite a few more developers will be deterred. > > 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. Perfectly usable, yes, but it adds a boatload of additional maintenance cost and installation headache to the core python codebase. The framework based build of Python has existed since the NeXT days along with a number of unnecessary, platform specific, modifications to the core codebase to support NeXT and it has been a constant source of headaches. The end result is that the version of Python on NeXT and, now, OS X has typically lagged behind the version available on other-- more mainstream-- platforms by anywhere from days to months. Certainly, OS X's popularity will reduce that gap, but why have a gap if it can be avoided entirely and comfortably? Furthermore, the chances of Apple shipping a framework build of python as a part of the system are pretty slim as the framework build of python doesn't add much to the capabilities of the language and incurs a bunch of additional maintenance/support headaches for Apple (i.e. do they have to ship a separate version for, say, Darwin??). Not that Carbon support in Python does not require the framework build -- it is just the extended Mac Python IDE / Dev environment that requires the framework (mostly because the build of it is currently quite broken). > > 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 ;-) ;-) I think of Python + Cocoa via PyObjC as being at the same level as, say, AppleScript Studio. Python provides the high level, easy to author, development language similar to AppleScript (though easier) while PyObjC provides the glue into the Cocoa frameworks. Frankly, given the comparative cleanliness with which Python interacts with ObjC across the PyObjC bridge, the Python solution is a hell of a lot simpler and easier to deal with than AppleScript Studio -- not a criticism of Studio, just the realities of building AppleScript based development tools. The proof is in the code -- I'm going to stop blathering now and actually put together a proper / easy recipe for creating Python based Cocoa apps and commit that into the repository... b.bum |