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
>> [EMAIL PROTECTED]
>
> _______________________________________________
> Pythonmac-SIG maillist - Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
