[Pythonmac-SIG] Installing wxPython with ActivePython and OSX

[Trent Mick]

[Trent]
> >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
      http://www.wxpython.org/download.php
  Some of that info is misleading:

  '''wxPythonOSX needs a "Framework" build of Python 2.3, also known as
  MacPython-OSX.'''

  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 you
  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 one.

  As well, some mention of the x86 arch issues would be helpful for
  users.

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 the
> >   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 *is*
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

-- 
Trent Mick
TrentM at ActiveState.com