[Pythonmac-SIG] Installing wxPython with ActivePython and OSX
kevino at theolliviers.com
Mon Apr 24 21:04:38 CEST 2006
Hi Trent, Bob, etc.
Sorry for the late reply. It's been a busy week. I've altered
wxPython's downloads page to hopefully be clearer and more up-to-
date. As for the ANSI/Unicode issue, I made Unicode a little more
prominent but ANSI still gets quite a lot of downloads, so I'm
hesitant to make it hard to get to. But I've made the Unicode builds
the first ones so as to encourage those who don't know/care to just
click on Unicode, so if that does make a big difference in the number
of people who download ANSI, we can re-evaluate moving it later. (I
simply don't know how many people actually need the ANSI build for
their app to work...) I also added the Universal binaries pre-release
build, along with a note explaining the Tiger-only issue and giving a
blueprint for lipo'ing the PPC and Universal builds if anyone wants
to try that to see if it works on Panther. ;-) (I don't have time to
attempt it right now.) URL is here:
On Apr 17, 2006, at 1:26 PM, Trent Mick wrote:
>>> wxPython on the Mac seems to be painful right now.
> [Kevin Ollivier wrote]
>> Suggestions and contributions welcome! :-)
> My apologies, I was being unfairly brief.
> Some suggestions:
> - A review of the Mac OS X-related text on
> Some of that info is misleading:
> '''wxPythonOSX needs a "Framework" build of Python 2.3, also
> known as
> To be fair explaining the myriad Python's out there for Mac OS X is
> hard. This sentence though connotes the wrong thing: that
> wxPython is
> only available for Python 2.3.
> '''If you would like to try Python 2.4.x on Panther or Tiger then
> can get an installer here'''
> Again, to be fair, giving a download link for the current Python for
> Mac OS X (whatever that really means) is a moving target. There
> *is* a
> Python installer at that link, but it is no longer a recommended
> As well, some mention of the x86 arch issues would be helpful for
> Okay, *one* suggestion. :) I don't currently use wxPython at all.
>>> 1. You need to get the correct build for your version of Python. For
>>> ActivePython 2.4.x or MacPython 2.4.x that means getting one of
>>> builds with "-py24" in the package name.
>> Of course, this is pretty much the same as with every other (binary)
>> Python extension, isn't it?
> Yes, I didn't mean to imply that wxPython is special here.
>>> 2. They have "ansi" and "unicode" builds. From what I can tell the
>>> "ansi" builds are probably only useful for Mac OS X 10.2.x
>>> compatibility. If you are using Mac OS X 10.3 (Jaguar) or greater
>>> then I'd stick with the "unicode" builds.
>> The ansi builds are for people who haven't considered Unicode support
>> when building their wxPython apps, and thus might have issues when
>> their data is automatically converted to and from Unicode. In ansi
>> mode, it just passes the actual 'bytes' around, so the user is in
>> total control over how the data is encoded. It took me a couple days
>> of auditing my codebase before I got everything working with Unicode,
>> and while I'm glad I did, up until that point I (and users of my app)
>> were doing just fine with ANSI builds.
>> But yes, in general, Unicode is the recommended build on OS X, or any
>> modern platform for that matter.
> If that is the case then I'd suggest having the link to the unicode
> build the only obvious one. Those requiring ANSI builds can be pointed
> to the SF.net "Files" page and/or a Unicode vs. ANSI wiki page.
> The current http://wiki.wxpython.org/index.cgi/UnicodeBuild, which
> linked to there, probably already does a good job here.
>> There aren't any Intel-only binaries, but packages containing
>> Universal binaries (built using the Universal MacPython Framework)
>> was finished up late last week and are just awaiting being uploaded
>> to the wxPython SF site. So it should be pretty soon.
> That's good news.
>>> Unfortunately I was also able to *install* it on Mac OS X 10.4/
>>> Intel but it doesn't work (importing "wx" fails) because the
>>> binary modules in wx are for ppc while the running Python is x86.
>> Right. About the only thing we could do at this point is to add a
>> command-line check on the architecture of the Python binary and bomb
>> out if it's incorrect. I could go ahead and add such a test, although
>> I think the OS X Installer will just give a generic "you are not
>> allowed to install this package" message, which is arguably just as
>> confusing to the user.... We could also add ppc to the filename,
>> though I think it will easily be missed.
> Yah, Apple's packaging tools are a pain. Great for braindead simple
> stuff, but quite limiting for anything custom.
> Trent Mick
> TrentM at ActiveState.com
More information about the Pythonmac-SIG