[Pythonmac-SIG] Installing wxPython with ActivePython and OSX

[Charles Hartman]

Excellent!

Problem, though -- a bone-dumb one, I'm quite sure, but I'm living  
proof that the unsavvy can run into it:

On my Intel iMac I downloaded and installed
	1. the Universal-MacPython-2.4.3.dmg (it made a new Applications/ 
MacPython 2.4
		folder, beside my existing Applications/MacPython-2.4 folder)
	2. the wxPython2.6-osx-unicode-2.6.3.2rc1-universal10.4-py2.4.dmg
In the Terminal "python" gives me the expected version, but "import  
wx" gives:


Python 2.4.3 (#1, Mar 30 2006, 11:02:16)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import wx
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "//Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/wx-2.6-mac-unicode/wx/__init__.py", line 42,  
in ?
     from wx._core import *
   File "//Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/wx-2.6-mac-unicode/wx/_core.py", line 4, in ?
     import _core_
ImportError: Failure linking new module: /Library/Frameworks/ 
Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac- 
unicode/wx/_core_.so: Library not loaded: /usr/local/lib/wxPython- 
unicode-2.6.3.2/lib/libwx_macud-2.6.0.dylib
   Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ 
lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/_core_.so
   Reason: image not found
 >>>

Charles Hartman

P.S. I had /usr/local/bin in my path before. Now I've got:

PATH=/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/ 
local/bin:/ . . .





On Apr 24, 2006, at 3:04 PM, Kevin Ollivier wrote:

> 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:
>
> http://wxpython.org/downloads.php
>
> Thanks,
>
> Kevin
>
> On Apr 17, 2006, at 1:26 PM, Trent Mick wrote:
>
>> [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
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig