Re: [Visualpython-users] One more stab at OS X compatibility

[Dethe E. <de...@li...>]

Hi Martin,

> Adding it to Fink's 10.4/unstable tree is a matter of seconds, so I  
> just
> did it.

Thanks for putting this together.  I switched to unstable and was  
able to install visual-py25 without problems.  I haven't exercised it  
extensively yet, but I can open a window and create basic shapes  
(sphere, cube). [Update: I took some time to run it over some more  
(much more) complex examples and haven't had any trouble]

> I am, however, not completely comfortable with these pythonXX  
> variants,
> because I don't know if they wouldn't ultimately also require
> corresponding variants for the boost-python libraries. Currently I am
> building the libboost_python libraries with the version of python that
> comes with OSX, which is python-2.3. This is then linked into the
> cvisualmodule.so which is ultimately run under python-2.5. On starting
> vpython2.5, the python shell complains mildly about differing APIs,  
> but
> in my (very few) tests it did run correctly. I cannot exclude that  
> there
> will be other situations where this leads to serious problems, though.

When I import visual, I do get the following error, although it  
appears to work OK:

 >>> from visual import *
/sw/lib/python2.5/site-packages/visual/array_backend.py:1:  
RuntimeWarning: Python C API version mismatch for module cvisual:  
This Python has API version 1013, module cvisual has version 1012.
   import cvisual

I assume that is the warning you were talking about?

Under the assumption that Python2.5 extensions were binary  
compatible, as long as it was the same version, I naively tried  
moving cvisualpython.so and visual/ to the site-packages directory of  
my framework build of Python2.5, but no such luck:

 >>> from visual import *
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/visual/__init__.py", line 15, in <module>
     import array_backend
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/site-packages/visual/array_backend.py", line 1, in <module>
     import cvisual
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/cvisualmodule.so, 2): Symbol not found:  
_PyType_GenericAlloc
   Referenced from: /Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/cvisualmodule.so
   Expected in: /Library/Frameworks/Python.framework/Versions/2.5/ 
Resources/Python.app/Contents/MacOS/Python

> Rearranging the packaging of the boost libraries so that the
> libboost_python libs would inhabit different packages corresponding to
> different python versions would require some work for which I haven't
> had the time yet.

Well, I certainly appreciate what you've done so far.

> So for now I am just waiting for reports on working/non-working
> visual-py25 (and visual-py24 for that matter) installations.

Looks good here.

>> Ultimately, some are hoping for a vpython that does not require fink.
>> Do you have an opinion as to what might be the best path towards  
>> that??
>
> I am not the right person to ask about this. In my opinion, every Mac
> user should install Fink ;-)
>
> What might be more interesting is to get rid of the X11 dependency and
> build a vpython that runs with Apple's python and aqua graphics.  
> Fink or
> not Fink is not the question.

I think you've nailed the crux of the matter.  What is wanted is (in  
order of importance):

1. Run under Aqua with no dependencies on X11 (and thus no need for  
gtk libraries)
2. Integrate with other tools that run under a framework build of  
Python (so, for instance, VPython programs could be packaged with  
py2app, could run in the same process as PyObjC programs, could  
interact with PyGame, etc.)

I think there is some resistance to Fink because of perhaps some  
instability in earlier versions, but more importantly, because Fink  
tends to bring along more Linuxisms and retain a dependency on X11  
rather than integrating with Aqua.  At least, that has been my  
impression, whether fairly or not.

>> Untangling vpython from its boost dependencies does not seem  
>> realistic.
>> I see that you maintain the boost fink packages.  But is boost itself
>> dependent upon fink if it is to be used as a dependency on OS X??

I could live with (but never love) Boost, if VPython could play  
nicely as an OS X citizen (no X11, framework build of Python).

Thanks also for the insights into how Fink packages are built.  That  
process has been opaque to me up until now, but I feel like you've  
given me enough to get started.

--Dethe

"Why is Virtual Reality always posited in terms of space, when time  
is the only real commodity left?" --Rich Gold