[Pythonmac-SIG] Extensions for static versus framework MachoP ython

[Julian Adams]

> > [I hadn't replied to your mods yet, as I didn't get around 
> to it, but I 
> > might as well do so now]
> >
> > I know, but it has a major problem in that -flat_namespace 
> will take any 
> > symbol with the correct name and simply assume it is the 
> symbol needed. 
> > This is an accident waiting to happen, and I'm heavily 
> opposed to it. I 
> > know that for unix-Python this is the norm, but it leads to 
> very obscure 
> > bugs.
> 
> But we'd have lots of good company...
> >
> > And note that these bugs aren't theoretical, either. I've 
> been bitten by 
> > it twice over the years, once because both SGI's original 
> GL library and 
> > curses had a clear() function, and once because the SGI compression 
> > library contained a modified version of the IJG JPEG library with 
> > unmodified external names so anything that was linked 
> against the normal 
> > jpeg library would be dead.
> 
> If something fails everywhere else, it should, by default, 
> fail on a Mac. 
> If we have special Mac machinery that would allow it to 
> succeed, we should 
> engage that machinery consciously and be aware that software 
> depending on 
> such Mac specific features isn't portable. IMO, the default 
> installation 
> should be bug compatible across platforms.
> 

that's never necessarily going to be the case. ms windows dll's work in a
different way to mac / unix frameworks / shared objects, and some knowledge
/ support is required to make code work on all platforms

> We can always tweak various things for the binary distribution, which 
> should cater to the majority, and we might find, e.g., that 
> most people 
> want two-level namespaces. Such adjustments can be made at 
> build time by 
> setting environment variables.

or configure script options ?

> 
> >
> > The first case (some Python script importing both the gl and curses 
> > modules) happened in exactly one Python script in the world: 
> > test.regrtest. The second case was really nasty, though, 
> because image 
> > processing apps might easily import both PIL and cl without 
> being aware 
> > of it. I'm very glad that MacPython has never had these 
> problems (because 
> > external symbol and library are matched up), and so when 
> Apple made this 
> > functionality available for OSX with the two-level namespaces I 
> > immediately jumped on the bandwagon.
> 
> There's no compelling reason I can see to get off the 
> bandwagon. The price 
> of admission is that the libs you link against are going to 
> get loaded 
> along with the module. The main library doesn't care how modules are 
> linked.
> 
> One reason the "two Pythons" problem even comes up is that 
> there are now 
> two fundamentally different ways to install Python, resulting 
> in two sets 
> of everything. I think this is a bad situation. We can avoid the 
> duplication with linked frameworks.

although you later quoted precedent for linked frameworks from apple they do
kill one of the big advantages of frameworks (to the user) - deleting
frameworks removes all the associated files. IMHO frameworks are Apples
alternative (and equally) neat solution to package management. over a long
period of time every unix box I've ever worked on has build up a cruft of
homebuild files in /usr/local, uncontrolled by any packaging system, and it
would be good to avoid this, especially if Apple provide a viable system.

i agree it's ugly to have 2 pythons, but in some ways Mac OS X is 2
operating systems, or layers: UNIX + NEXT. while you could treat a Mac box
as a vanilla unix box this deprives you from a whole raft of goodies which
make Mac OS, well, Mac OS.

personally I think Macho Python should exploit all those goodies by default,
from a source build. otherwise it won't be a first class player in the Mac
world. it shouldn't be difficult to optionally maintain / build a lowest
common denominator unix version. some people will want this (e.g. to develop
fully portable scripts),but I doubt it would be a majority.

> 
> >
> > But again: if enough people here feel that the benefits of 
> > -flat_namespace outweigh these problems, please speak up! 
> I'm always will 
> > to (grudgingly:-) bend to the majority...
> 
> I think cross platform modules should, by default, be linked 
> to behave as 
> they do on other platforms even if that means behaving badly 
> in some ways.
>   Mac docs should note the default, outline its practical 
> consequences, 
> mention the workarounds possible on Mac OS X, and remind users that 
> software depending on these platform specific tricks is not portable.
> 

you might guess that I think we should use Mac specific stuff, to prevent
the issues outlined above, as long as it doesn't generally cause other
platforms problems.

> For Mac only stuff like the binary distribution, just link 
> the best way. 
> We have complete control over the Mac only build process and 
> how things 
> get compiled for the binary distribution.

I thinks it's important for it to be as easy as possible to build the binary
distribution from source, as easy as on a unix platform. Probably the full
Mac version would be the default, as most Mac people would want this. The
unix version would be a configure option.

It strikes me that a "vanilla" unix build would be rather crippled, as there
is no X server / TK on Mac by default.

<snip>

> 
> In keeping with the trend toward a "standard" Macho binary 
> distribution, 
> which I applaud, I suggest the first step should be to move 
> all the mac 
> specific stuff (or as much as we can) out of the core build 
> mechanism. In 
> particular, there should be no hint of frameworks there. On a 
> Mac, running 
> "./configure; make; make install" should produce what we'd 
> expect on any 
> other *NIX: a library in /usr/local/lib etc. Call this the "generic" 
> installation.
> 

you might guess by now that I disagree with this ...

> The Mach-O binary distribution should, IMO, install over the generic 
> installation. (Or it could do the generic installation as a 
> first step. 
> Whatever.) We might want a minimal "Darwin only" option and a 
> "Mac OS X" 
> option to install pieces that link to libraries not found on Darwin.

... and also with this ! why should the Macho distribution be primarily
binary ? since the source would be available I guess you mean "non standard
or hard to build", which would suck.

> 
> I would urge that supporting two totally different 
> installation schemes 
> such as "standard" and "real framework" is asking for trouble.
> 
> A linked framework would make the Mac binary distribution an 
> Installer 
> package, but I'd note that Apple recommends drag and drop 
> only for "simple"
>   installations. If uninstallation is a requirement, we can 
> provide an 
> "Uninstall" option with the package.

having a self contained package would void any need for an installer :)

> >
> > The question is really one of "should MachoPython behave 
> like a Macintosh 
> > package or like a unix package", and my answer would be 
> "like a Macintosh 
> > package".
> 

oh yeah !

<snip>

...these are observations of a unix guy, who's a Mac OS X convert.

julian