[Pythonmac-SIG] Some thoughts on Python and OS X

[Markus W. Weissmann]

On Jun 14, 2004, at 07:54, Bob Ippolito wrote:

>
> On Jun 14, 2004, at 1:28 AM, Kenneth McDonald wrote:
>
>> The following comes from some experiences I've had recently whilst
>> wrangling with wxPython/SPE, plus some others encountered in the
>> past while doing custom installs of Tk and tkinter. I don't want to 
>> start
>> any flame wars, and I certainly don't want to hurt any feelings--the 
>> Python
>> people at Apple are doing a great job, and I really appreciate their
>> effort. However, the "Apple Philosophy" as applied to Python (and
>> indeed as applied to much of the UNIX subsurface in OS X) is making
>> things painfully, and in my opinion unnecessarily, difficult to use.
>>
>> First, the obvious: Having a "required, custom" build of Python on
>> OS X is a Bad Idea. Last I heard, this was the official OS X way of
>> doing things, i.e. the Python you got was what you should use, don't
>> try replacing it, and no, it's not a stock Python. I believe this has 
>> been
>> recognized to be a problem and is being worked on--sorry if I'm
>> ignorant of recent fixes, I "threw out" the stock OS X Python some
>> time ago, as I needed my own custom compilations.
>
> It's not custom.  It's highly suggested not to replace it because 
> there are
> various bugs here and there on the Python side that make it a bad idea 
> to do so.

as an Unix-migrant you might see at least the site-packages path as 
being 'custom'.

>
>> In general (and I'm sure the Apple techs understand this, but perhaps
>> you could pass this on to those in management who don't?), DON'T
>> EVER take a community standard tool such as Python and "improve"
>> it in such a manner as to make it incompatible with what people have
>> come to expect. If you must produce an Apple-specific version which
>> requires special consideration when being used with other packages,
>> then observe the following:
>>
>> 	1) The _standard_ version should be the standard; even on OS X.
>> 	People who want to use Python without caring about the OS its
>> 	on will then be able to use it properly. Those who want to make use
>> 	of the os-enhanced version will know what to do.
>>
>> 	2) Make sure that an 'enhanced' version can coexist peacefully with
>> 	the standard version.
>
> It *is* standard.  It's not "improved".  The only difference between 
> what Apple distributes and what was in 2.3.0 is the location that it 
> is installed in (/System rather than /) and the additional 
> CoreGraphics extension, which has nothing to do with how it was 
> compiled.
>
>> One of the things that is expected is that I can download, compile,
>> and install a more recent version of Python without problem (assuming
>> the newer version itself doesn't have problems.) Another is that
>> add-ons for Python which have been written to install nicely in a
>> generic UNIX environment should continue to do so under OS X.
>
> It will work just fine, but it must supersede the system installation 
> due to bugs that were in 2.3.0 that we can not fix.  Once you install 
> your own Python, you can no longer expect to be able to compile 
> software for the stock 2.3.0.
>

huh? I have a non-apple installation of python here on my machine, 
though
apple's python still works. (of course I didn't install it into /usr...)

> Any Python extensions that have been written properly already use 
> distutils, and thus already work fine on OS X.  If anything is 
> designed to work in a "generic UNIX environment" and does NOT work on 
> OS X is simply not done correctly.  Things should work on Windows too, 
> and that means using distutils.
>

thats _not_ true.
1. OS-X is a bit picky about compiling stuff (-> flat_namespace etc.) - 
many SWIG generated
wrappers fail with apple's python
2. On stock OS-X you are doomed if you need /dev/dsp for sound (Dan 
Christiansen is developing
a kext to fix this at least on OpenDarwin)

>> Next, paths. I can understand why Apple (actually, probably NeXT)
>> decided to come up with improvements on the UNIX file structure.
>> But why, oh why, couldn't they have maintained some sort of backward
>> compatibility using links? I've effectively recreated my own UNIX file
>> structure using links, to make up for this, and would be surprised if 
>> others
>> haven't as well. In particular, why the heck isn't there the 
>> equivalent of
>> /usr/local? Having this basic de facto standard sort of file 
>> structure in
>> place would save us UNIX software users countless hours in headaches.
>> Yes, it's easy to argue that the problems are the fault of bad 
>> installation
>> scripts and makefiles. Well, yes, in theory that's probably true; but 
>> so
>> what? The point of software is to be a useful tool, not to drive the 
>> customer
>> crazy by insisting that somebody else, in assuming a de facto 
>> standard of
>> the time would continue into the future, made a mistake.
>
> Uh, there is a /usr/local.
>

and just in case there isnt:
"sudo mkdir -p /usr/local" :)

>> I find this a particular problem when it comes to Frameworks and 
>> Libraries.
>> Here's a typical example of installing a couple of Python modules 
>> recently:
>>
>> 1) Compile module A--works, great. Install it. Where the heck are the
>> files? Do a search on the disk. Ah, there they are in
>> /Library/Frameworks/Python/.../.../... and so on 
>> .../2.3/site-packages.
>> Create a link from a more reasonable location so they'll be on the
>> python path.
>
> /Library/Python/2.3 is the more reasonable link, it already exists.
>

ever tried to install mod_python with apple's python? You'll get the 
modules clobbered
somewhere into /System - and it wouldn't work if you just moved them to 
/Library/Python/2.3.

>> 2) Compile and install module B. Where is it? Disk search. Ah, it's in
>> /Library/Python/2.3. Create link. Why did it end up here, vs. Module
>> A in Frameworks? Beats me.
>
> They're the SAME PLACE unless you or some broken installation script 
> screwed that up.
>
>> And why, for that matter, are all of these modules always ending up in
>> a '2.3' directory? I happen to know that some of them aren't dependent
>> on the Python binary, and it looks to me as if, when 2.3 changes to 
>> 2.4,
>> I'm gonna have some unnecessary work, again. Trust me, if a module
>> is incompatible with 2.4, I'll know it soon enough; you don't have to
>> force me to move everything manually to the 2.4 path.
>
> This happens on EVERY Python platform.  If you want to install 
> "version independent" Python files somewhere else, feel free to do so. 
>  There are many options that you may pass to distutils to control this 
> behavior.  Then you simply need to make a pth file that points to your 
> "version independent" site directory.

Bob is right - on Unix the modules are placed in 
PREFIX/lib/python2.3/site-packages/ by default;

>
>> None of this is going to make me move off of OS X, of course; it still
>> is, by far, the best OS for most users IMHO, myself included. But this
>> situation will cost Apple some money; I generally keep fairly 
>> up-to-date
>> with hardware, and was planning on getting a new Powerbook when
>> they hit 2 GHz. However, I've had to do so much manual tweaking to my
>> system that the effort needed to recreate that on a new drive is a 
>> little too
>> much to want to repeat in the forseeable future, so Apple's probably 
>> going
>> to have to hit 3GHz for me to decide it's worth the pain. (Yes, I know
>> I don't have to do a "clean" install of everything when I go to a new 
>> system,
>> but that's one of the things I do to help me clean all the cruft out.)
>>
>> I'm looking forward to what comes out in the future, I have a lot of
>> confidence in the Python people at Apple, and I have no problems at
>> all in continuing to pay for new versions of OS X which bring new
>> features and improvements. I just hope that the above is of some help
>> in deciding how some of those features should be implemented in the
>> future.
>
> There aren't really "Python people at Apple", at least not that I'm 
> aware of.  Any problems with the Python distribution for OS X are at 
> least partially our fault.  Start filing bugs and feature requests, 
> and making patches if you REALLY want a particular issue fixed in a 
> way that suits you.
>

hmmm... thats true - ever tried to install python on non-apple darwin? 
If ./configure
recognizes 'darwin' it doesn't care if your host is x86 - it just tries 
to compile for ppc.

> I think a lot of your troubles are just because you expect things to 
> work as they do in Linux, and that's just not the case.  There are 
> equivalent or better ways of doing things on OS X, that you either 
> don't accept or haven't figured out yet.


cheers,

Markus

---
Markus W. Weissmann
http://www.mweissmann.de/
http://www.opendarwin.org/~mww/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040614/fb2edb4e/PGP-0001.bin