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

[Ronald Oussoren]

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

it.

really interested in Y, which uses X, and then X forcing me to upgrade

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

OS-X 10.3.9 to 10.5.*, PPC and Intel, AND applications I build with

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

state.

python.org 2.5 Universal Framework, I'll get a python that will work on py2app will work on those platforms, AND extensions I build with it will encouraging people to use Apple's python with OS-X 10.5 will break that

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

for people building binaries to distribute.

complexity and questions on this mailing list, a LOT of extra complexity

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

directly Apple-endorsed)

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

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.
"""

This was discussed a lot a while back, mostly on the context of what the

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.

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:


replace the whole existing Python with something new"

is


have to replace not only python, but all the extra packages I had
already installed"



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?

Anyway, the reason to make that recommendation up front was that it's a "as soon as I want to install one little add-on module I have to first "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 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

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 --


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!

1) it's really not that rare to have to compile things -- and maybe you

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

[EMAIL PROTECTED]
_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig