[Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger

Sun Dec 23 16:44:07 CET 2007

On 23 Dec, 2007, at 9:01, Christopher Barker wrote:

> Jack Jansen wrote:
>> The real problem is when I couldn't care less about package X but I'm
>> really interested in Y, which uses X, and then X forcing me to  
>> upgrade
>> it.
>
> Just to make sure I understand -- is this an example of that:
>
> I want to use wxPython (the most recent version). I expect to have to
> install that, but now the website tells me that I need to install the
> python.org python before I can use wxPython. Yes, that is annoying,  
> but....

That should be a documentation bug, either that or their installer  
sucks. Any framework build of python2.5 on OSX can use extensions  
build using any other framework build of python2.5. This is by design,  
back in the old times (OSX 10.1 and python2.3 IIRC) we had some  
serious problems with that (e.g. you build an extension with one build  
of python, use it with another build and get some very hard to  
understand or debug error messages).

>
>
>> Python is in a pretty good shape right now, with well-packaged
>> extension modules being compatible with a fairly wide range of Python
>> installations, but please let's try and keep it that way.
>
> Keep it what way? My experience and reading tells me that if I use the
> python.org 2.5 Universal Framework, I'll get a python that will work  
> on
> OS-X 10.3.9 to 10.5.*, PPC and Intel, AND applications I build with
> py2app will work on those platforms, AND extensions I build with it  
> will
> also work on all those platforms (with the same Python anyway). That's
> the state of affairs that I'm trying to keep. It appears that
> encouraging people to use Apple's python with OS-X 10.5 will break  
> that
> state.

The right way (TM) to go forward is investigate what causes these  
problems and fix them, not tell people to reinstall the same version  
of Python they already have on their system.

>
> I don't run 10.5, but from what I've seen, it's just introduced
> complexity and questions on this mailing list, a LOT of extra  
> complexity
> for people building binaries to distribute.

I've seen two types of problems:

1) Apple's build is slightly broken in that it doesn't build universal  
binaries

2) If you have both Apple's build of python and the Python.org build  
on the system people get confused

I've also found, and *fixed*, a problem in the code in distutils that  
determines if it is possible to universal binaries on the current  
platform.

>
>
> Jack Jansen wrote:
>> I think this would be a very good idea, even if only from a  
>> "political"
>> point of view.
>
> well, yes, the politics are relevant.
>
>> Even though I've been an open source developer since long before the
>> word existed I find that I'm getting sick and tired of the
>> reinvent-the-world attitude that is far too common in the open source
>> community.
>
> I really don't think this is re-invent the world.

Why do you think it isn't?   Your suggestion is just as annoying as  
Fink or MacPorts which insist on installing software I already have on  
my system.  I understand the technical reasons for doing this (it  
makes QA a bit easier), but that doesn't make it less annoying.

>
>
>> If I am new to Python on the Mac and I've played with Apple Python a
>> little, but as soon as I want to install one little add-on module I  
>> have
>> to first replace the whole existing Python with something new (and  
>> not
>> directly Apple-endorsed)
>
> This was discussed a lot a while back, mostly on the context of what  
> the
> common Python-on-Mac web sites should recommend to newbies.
>
> http://wiki.python.org/moin/MacPython/PythonDistributionsForMac
> """
> Mac OS X comes with a pre-installation of Python, usually one or two
> years old. This can be sufficient for some needs, but the MacPython
> community recommends installing a newer, more capable, version.
> """

That was true on 10.3 and 10.4, but not on 10.5. The version on 10.5  
is the bleeding edge of the stable branch and includes features that  
the Python.org tree does not (dtrace support).

>
>
> seems to be what was settled on then. Maybe Apple's python really is
> good enough to be considered the "default", but I have my doubts.
> Anyway, the reason to make that recommendation up front was that  
> it's a
> lot less bothersome to new users to say:
>
> Want to try python? -- install this, then, when you need any extra
> packages, get them here.
>
>
> Then to get them used to using the built-in one, but when you start
> doing something "real", you need to go get another one. To use your
> example, far worse than:
>
> "as soon as I want to install one little add-on module I have  to  
> first
> replace the whole existing Python with something new"
>
> is
>
> "after using Apple's python for a while, and installing a bunch of  
> extra
> packages into it, I now discover that it won't work for my needs,  
> and I
> have to replace not only python, but all the extra packages I had
> already installed"
>
>
> Will that happen? I don't know, but I suspect it will. And frankly,  
> once
> you're downloading and installing one thing, two isn't really a big  
> deal
> -- unless you suffer from very limited bandwidth. OH, and it sounds  
> like 
> we're proposing asking new users to install a "Apple'sPythonFix"  
> package
> anyway, so the ONLY difference is bandwidth, and the fact that you're
> not using the version from Apple -- is there really anyone that ONLY
> runs Apple software?

I'm proposing an "MacPythonAddons" package that will install some  
useful stuff on top of Apple's stuff. That will include a number of  
small bugfixes, but mostly additional software that will make life  
easier for new developers (such as an .app bundle for IDLE).

Note that I don't want to get into a discussion on the quality of  
IDLE. As far as I'm concerned it is good enough for casual development  
and I haven't found a proper replacement yet.

The important bit in my proposal is trying to improve things, instead  
of whining how Apple has always provided a broken Python installation  
and will forever do so.

>
>
>> it's mightily inconvenient. Also note that the chances that the
>> distutils fix or the 64-bit fix are likely to affect me are exactly  
>> zero
>
> Not so. The distutils issue effects you in two ways --
>
> 1) it's really not that rare to have to compile things -- and maybe  
> you
> want to use py2app to distribute something.
>
> 2) You want binaries from someone else, and they aren't right, because
> they compiled them with Apple's python.
>
>
> Anyway, I'd love it if Apple's Python really could meet all of our
> needs, so go prove me wrong!

Apple's python won't work 10.4, but who cares. Several prominent  
developers of software that runs on MacOSX have stated that they will  
no longer develop software that targets 10.4 or earlier and I agree  
with them.

OSX 10.5 is a major leap forward for the platform, and more so for  
developers than for end users.

>
>
> Oh, and one way or another, someone should update that Wiki page for  
> 10.5.

Be my guest, I don't have time for it.

Ronald

>
>
> -Chris
>
>
> -- 
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20071223/e47f63fa/attachment.bin 