Re: [cgkit-user] [cgkit-commits] CGkitinfo Error

[Matthias B. <mat...@gm...>]

david vandergucht wrote:
> Well, to be exact, i had trouble installing the whole package, as well as
> pygame, on my out of the box Osx with apple's compiled 2.5.1 python in it.
> The .pkg of both cgkit and pygame didn't want to install because it was
> needing a "System Python Install" ... 

Hm, I was just creating the package with the distutils and the mpkg 
extension. Frankly, I don't know what exactly the requirements of those 
generated packages are...

> The python installation folder in my
> case was 
>  1)     /System/Library/Frameworks/Python.framework/Versions/2.5/
>  and i've seen that the .pkg was installing well with the existence of the
> same path without the /System/ on front of it: 
>  2)    /Library/Frameworks/Python.framework/Versions/2.5/
> this is typically the path where activestate or pythonmac installs when
> they're downloaded.
> 
> I've noticed something else: installing pyOpenGL, numpy and pyProtocols was
> ok with no (visible) problem, and the lib were put by the installer in a
> third folder:
>  3)   /Library/Python/2.5/site-packages/
> 
> So i had the package of pygame and cgkit extract in the folder #2, and had
> to move the files in the folder  #3, in order to had it load from the
> python console..

What files did you extract from where? Did you unpack the mpkg file 
yourself? How exactly did you do that? (you may already have noticed 
that I'm still quite a newbie on OSX...)

> I also downloaded the sources from cgkit, just for me to see. And here,
> i've noticed two things:
> 
> (the python console is fired up from my basic home dir)
> First, a simple call from the console to cgkitinfo raise an error:
> 
>     >>> import cgkitinfo
>    Traceback (most recent call last):
>       File "<stdin>", line 1, in <module>
>     ImportError: No module named cgkitinfo

Well, application code needs to import via cgkit.cgkitinfo as all those 
modules are in the cgkit package (whereas the __init__ script from your 
previous mail was part of the package, so it could use a relative import).

So I take it building cgkit went fine? (where did you get Boost from?) 
In this case, you should just be able to install everything via "python 
setup.py install". Did that work? Or how did you try out the local build?

> Second, i have neither the viewer.py or the render.py in the freshly ".pkg"
> extracted folder in location #2 and copyied in location #3: I can only find
> those two files in the source archive. So i just copyied those two files
> from the source dir to the dir #3, just to be sure to not exec it from the
> source dir (i've also deleted it)

In the mpkg there are actually two individual packages: cgkit-platlib-* 
and cgkit-scripts-*
Apparently, the scripts are in the second one...?

> I've made the viewer.py working after modifying the __init__ .py, but for

I still think this is odd and shouldn't be necessary...

> now the render.py still doesn't work with 3Delight (and a ton of error)
> 
> [...]
>       File "C:\cygwin\home\pje\PyProtocols\src/protocols/_speedups.pyx",
> line 199, in _speedups.adapt
>       File "C:\cygwin\home\pje\PyProtocols\src/protocols/_speedups.pyx",
> line 188, in _speedups._adapt
>     TypeError: exceptions must be strings, classes, or instances, not
> AdaptationFailure
> 
> ... The one with the "C:\cygwin..." worries me a bit as i'm on Osx...

I have seen that one before. This is a problem in PyProtocols, not 
cgkit. You can workaround this problem by not using the C version of 
PyProtocols. When you build it, you can pass an option 
--without-speedups (or something like this, have a look at the docs or 
inside the setup script) to the setup script in which case it will 
install a pure Python version. The pure Python version does not have the 
above problem.

By the way, the Windows paths in the above traceback don't have to worry 
you. This just means the C sources of the Python extension module were 
generated on Windows (using Pyrex). As far as I know, the generated 
sources should be platform independent, so this is not a problem.

Thanks for testing that stuff...

- Matthias -