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

[Christopher Barker]

Ronald Oussoren wrote:
> I think we should start a small project for "MacPython Addons",

This looks very promising. Thanks for getting it going.

> this  project will install:
> 
> * Hotfix for distutils to ensure that distutils builds univeral
> binaries (32-bit only at first) * (possibly) hotfix to ensure that
> you can install '-fat-' eggs on 10.5 *
> /Applications/Python-2.5/IDLE.app

I don't have 10.5, so I'm only going on my memory of issues people have
complained about on various mailing lists:

  * How about readline?

  * What about people installing upgrades to packages? IIUC, the Apple
python puts stuff in a dir that is before site-packages, so if you
install a newer version of a package that Apple already had, it won't be
used without sys.path manipulations. I think numpy was the example at
hand, but assume the same issue would apply to wxPython etc.

Also, if people do upgrade packages like numpy or wxPython, or ???,
might that break any Apple system stuff if there are backward 
compatibility issues?

  * Will this allow folks to build a package (or egg) on 10.5 with
Apple's Python, and have it work with the Framework 2.5 python on 10.4? 
(and vice-versa?)

* Will py2app bundle up Apple's python, or assume it exists? If it 
doesn't, then will it know which packages to bundle?

I now I came across as a negative whiner about Apple's python early in 
this thread, but I think we all have the same goal here -- make it easy 
to use for newbies, and have it be as little work for the folks doing 
the real work on MacPython (not me!).

If all (or most) of the issues can be resolved with the Apple supplied 
python, I'm all for it.

Andrew Jaffe wrote:
> is 
> there any official "best practice" for Python under Leopard?

That is exactly what is being discussed here. If I have it right, then 
Ronald is proposing that a modest "hotfix" package will solve the few 
issues with the Python Apple supplies with 10.5, so we, as a community, 
can declare using it as a "best practice". We can then update the 
appropriate Wiki pages (and that I could actually help with!)

Jack Jansen wrote:
> I think that for "true" end users Idle is the only serious omission.

This is where I disagree -- what is a "true" end user? It's a complete 
continuum, from total newbie to hard-core hack-at-the-cpython-source 
developer. And, indeed, we hope that the newbies will move up the 
continuum as they get more experience.

 > The first one is really for developers only,

Who is a "developer?". I agree that folks like Ronald (for PyobjC) and 
Robin Dunn (for wxPython), can patch their systems to build binary 
packages the way they want. However, a LOT of binary packages for OS-X 
are build by folks different than the people developing the packages. 
These vary from newbies that download a tarball with instructions to 
type: "setup.py install", to folks like me that are less newbie, but 
really want a one-way-to-do-it package that I can give to my colleagues 
etc, and have it run on multiple systems, to folks that are trying to 
get an app bundled up with py2app that lots of other folks can run.

Ever since OS-X began, the net has been littered with various binary 
packages for python that are all compatible with different pythons: 
Apple's, fink, darwinports, Intel Only, PPC only,etc, etc, etc. It 
really will do the community a lot of good to consolidate that as much 
as possible, and having the "best practices" python build the "right" 
kind of package by default is critical to this.

Someone wanting to build and distribute a packages needs to be able to 
find instructions not more complicated than:

1) Download and install this: [hotfix package]
2) setup.py build
3) bdist_mpgk (or whatever the setuptools command is to build a binary egg)

 > and the second one doesn't
> really become important until such fat eggs become widely available 
> (which they are not right now, IIRC).

I don't know how you define widely, but they are becoming available -- 
matplotlib, scipy, numpy, etc.

-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