Using Rabbyt as a drop in package..

[Carrie]

Hi there!

Some of my beta-testers are unable to install Rabbyt on their Windows
machines. (There seems to be a installer issue with a 64-bit version
of Windows)

To work around this I thought I would try to use Rabbyt by directly
dropping the package files into my project. (That way the beta-testers
only need to have Python installed - and even less if it's a frozen
exectutable) My project structure looks something like this:

- main.py
- [game]
- - __init__.py
- - [data]
- - [rabbyt]
- - - __init__.py
- - - _anims.pyd
- - - _rabbyt.pyd
- - - _sprites.pyd
- - - anims.py
- - - collisions.pyd
- - - primitives.pyd
- - - sprites.py
- - [pyglet]
- - test_rabbyt.py
- - game_window.py
- - game_object.py
- - game_state.py

In 'main.py' I did this:

import game.rabbyt
print rabbyt.__version__

I expected to see '0.8.3' in my terminal but ended up with the
following error:

C:\Projects\Sparkster>C:\Python27\python main.py
Traceback (most recent call last):

File "main.py", line 2, in <module>
import game.rabbyt
File "C:\Projects\Sparkster\game\rabbyt\__init__.py", line 35, in
<modul
e>
from rabbyt._rabbyt import *
ImportError: No module named rabbyt._rabbyt

I copied the same two lines into 'test_rabbyt.py' and ran that. It
printed out '0.8.3'.

Does anyone know why this happened? It seems that I am only able to
import Rabbyt from a file directly in it's parent directory but not
any higher than that. If I move the 'rabbyt' directory so that it's a
sibling of 'game' I can then import it in main.py *but* I lose the
ability to use relative imports from files deeper in the hierarchy.
This only seems to be a problem with Rabbyt; I can access Pyglet
anywhere that's needed.

Any ideas?

Carrie

[Matthew Marshall]

Which version of python is installed? 64 or 32 bit?

32 bit binary modules won't work with 64 bit python. You need to have them match.

Note that 32 bit modules + 32 bit python works on 64 bit Windows. Last I looked into it, it was recommended to use 32 bit python even on 64 bit windows, as most of the binary modules available were only 32 bit. But it's been a while since I read that, so the situation might have changed.

If you want it to work regardless of if the user installed 32 or 64 bit python, maybe you could could include both versions of rabbyt in different directories. You could add the respective directory to sys.path depending on if python is 32 or 64 bit.

The platform.architecture() function might help: http://docs.python.org/library/platform.html#cross-platform

Hope that helps :-)

MWM

[Carrie]

Hi Matthew,

I think there are two issues here.

1. Some of my beta-testers couldn't install rabbyt on their machines.
2. I can't seem to import rabbyt when it's a sub-package in my
project.

I'm primarily concerned with the second issue because I really like
the idea of including rabbyt (and pyglet) directly in my project. It's
one less thing the user has to install and if I make a frozen
executable they only need to double click it to run the game.

My test Windows environment here uses Windows 7 (64-bit). I have the
32-bit version of python installed (no other python modules
installed). Rabbyt is in the project structure I listed above. It
appears to only work when I try to import it from the *immediate*
parent directory.

It's probably easier to see the error for yourself. Here's a stripped
down version of the project with just 'main.py' and 'test_rabbyt.py'
and a couple of folders with empty '__init__.py':

<http://www.mediafire.com/?avw41mbu4ryl4e8>

I can run 'test_rabbyt.py' and it imports fine (the version number is
displayed in my console). When I run 'main.py' it seems to find the
rabbyt package but raises'ImportError: No module named
rabbyt._rabbyt'. There is no '_rabbyt.py' so (to me) it looks like
it's having trouble reading '_rabbyt.pyd' - but only when it's a sub-
package. It seems to be ok when imported from the other file.

Any idea?

As for the installer issue I thought they were using the 32-bit
version of python but there's a chance that might really be the 64-bit
version (I have to ask them). The only other package for the game is
pyglet but since the latest version supports 64-bit python it never
threw any errors. The only other info I have about the issue is that
the installer never seemed to complete; it couldn't find the python
version on their machines. I just downloaded the installer and tried
it here and it appears to work fine. (I'll uninstall it in a second so
that I can concentrate on the second issue.)

> If you want it to work regardless of if the user installed 32 or 64 bit
> python, maybe you could could include both versions of rabbyt in different
> directories. You could add the respective directory to sys.path depending
> on if python is 32 or 64 bit.

Wait - I'm confused. Is there another version of rabbyt? I thought it
was only a 32-bit module?

Thanks, and I really appreciate your help! I love Rabbyt - I'd have to
really scale back my game if wasn't around. (or write it in another
language)

Carrie

[Carrie]

Was just trying a few things out and I noticed I had a small typo in
that file. Please ignore that first link and download this one:

<http://www.mediafire.com/?dy2cnus2ccsg2ea>

in 'main.py' it should read 'import game.rabbyt' and not 'import
data.rabbyt' on the first line. Still doesn't work - only now it makes
sense when you read it.

Sorry about that!

Carrie

[Matthew Marshall]

Ok, I understand the problem now.

Rabbyt uses absolute imports internally. So if the rabbyt package
isn't on the system import path the sub-modules won't be found.

I suggest adding the directory containing rabbyt to the module search
path when your game launchers. Here's a version of your main.py that
does this:

"""
import sys
import os.path
sys.path.insert(0, os.path.join(os.path.dirname(__file__), "game"))

import rabbyt
print rabbyt.__version_
"""

That should work for you. Although, I would be curious as to why some
of your beta testers had trouble installing rabbyt. Was there any kind
of error message with the installer?

Oh, and I thought I had built 64 bit versions for windows, but looking
again I only see a 32 bit version uploaded.

MWM

> --
> You received this message because you are subscribed to the Google Groups "Rabbyt" group.
> To post to this group, send email to rab...@googlegroups.com.
> To unsubscribe from this group, send email to rabbyt+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rabbyt?hl=en.
>

[Carrie]

> Rabbyt uses absolute imports internally. So if the rabbyt package

> isn't on the system import path the sub-modules won't be found.

Ah.. I thought it might be something along the lines of this. Is this a result of using Pyrex to create the extension or is this something that is common with all dlls/extensions in general?

> I suggest adding the directory containing rabbyt to the module search

> path when your game launchers. Here's a version of your main.py that

> does this:

> 

> import sys

> import os.path

> sys.path.insert(0, os.path.join(os.path.dirname(__file__), "game"))

> 

> import rabbyt

> print rabbyt.__version_

That worked like a charm (thank you!) Will path manipulations cause any issues in frozen binaries?

> I would be curious as to why some

> of your beta testers had trouble installing rabbyt. Was there any kind

> of error message with the installer?

Here's two screenshots with the exact error:

<http://img189.imageshack.us/img189/394/rabbytinstall1.png>

<http://img20.imageshack.us/img20/6406/rabbytinstall2.png>

These were on Vista 64-bit. (Although I think the same thing has been happening with Windows 7) One person did have XP x64 (I didn't even know XP had a 64-bit version) but he said he was finally going to upgrade his computer this semester and that I shouldn't worry about it.

I believe that's the second screen of the setup - normally it should read 'Python Version 2.7' (found in registry) They did have python installed and one person did get back to me (he did confirm that his python was 64-bit and that he had tried the latest version on the package index)

I was trying to investigate it a little further at the time and found this bug: 

<http://bugs.python.org/issue6792>

It *sounds* like it's an issues with how the distutils creates the setup package so I don't think there is anything you can really do on your end. It's not clear to me in that thread whether they even agree that it's worth fixing or not.

> Oh, and I thought I had built 64 bit versions for windows, but looking

> again I only see a 32 bit version uploaded.

So there is a 64-bit version then? It just wasn't posted? I looked on your bitbucket project page but it doesn't look like it had any recent changes.. Is that the most up-to-date place to get the source? 

I sent an updated version of Sparkster (with the new sys.path modification) to that one tester. He send this back:

C:\Users\Jason\Downloads\Sparkster-Carrie>C:\python27\python main.py

Traceback (most recent call last):

  File "main.py", line 5, in <module>

    import rabbyt

  File "game\rabbyt\__init__.py", line 35, in <module>

    from rabbyt._rabbyt import *

ImportError: DLL load failed: %1 is not a valid Win32 application.

So it looks like the 0.8.3 version that I have is still only compatible with python 32-bit. What is the issue that is preventing 64-bit compatibility? Is it the way a 64-bit cpu handles numbers? That shouldn't be too hard to fix. If we can get it working on a 64-bit machine I could include 2 rabbyt directories with the project and load the correct one based on their architecture and version of python installed.

Thanks so much for helping with this!

Carrie

[Matthew Marshall]

On Thu, Jul 5, 2012 at 4:18 AM, Carrie <carri...@rock.com> wrote:
>> Rabbyt uses absolute imports internally. So if the rabbyt package
>> isn't on the system import path the sub-modules won't be found.
>
> Ah.. I thought it might be something along the lines of this. Is this a
> result of using Pyrex to create the extension or is this something that is
> common with all dlls/extensions in general?

This is common to all python packages, at least any that use absolute
imports for sub modules. (Which is the recommended way to do if IIRC.)

>> I suggest adding the directory containing rabbyt to the module search
>> path when your game launchers. Here's a version of your main.py that
>> does this:
>>
>> import sys
>> import os.path
>> sys.path.insert(0, os.path.join(os.path.dirname(__file__), "game"))
>>
>> import rabbyt
>> print rabbyt.__version_
>
> That worked like a charm (thank you!) Will path manipulations cause any
> issues in frozen binaries?

I think this is what most 'frozen binary' tools do themselves. They
bundle up the dependencies and add them to the path when you run.

>> I would be curious as to why some
>> of your beta testers had trouble installing rabbyt. Was there any kind
>> of error message with the installer?
>
> Here's two screenshots with the exact error:
>
> <http://img189.imageshack.us/img189/394/rabbytinstall1.png>
> <http://img20.imageshack.us/img20/6406/rabbytinstall2.png>
>
> These were on Vista 64-bit. (Although I think the same thing has been
> happening with Windows 7) One person did have XP x64 (I didn't even know XP
> had a 64-bit version) but he said he was finally going to upgrade his
> computer this semester and that I shouldn't worry about it.
>
> I believe that's the second screen of the setup - normally it should read
> 'Python Version 2.7' (found in registry) They did have python installed and
> one person did get back to me (he did confirm that his python was 64-bit and
> that he had tried the latest version on the package index)
>
> I was trying to investigate it a little further at the time and found this
> bug:
>
> <http://bugs.python.org/issue6792>
>
> It *sounds* like it's an issues with how the distutils creates the setup
> package so I don't think there is anything you can really do on your end.
> It's not clear to me in that thread whether they even agree that it's worth
> fixing or not.

Yeah, it sounds like this is just a matter of mismatched 64 vs. 32 bit
python vs extensions.

>> Oh, and I thought I had built 64 bit versions for windows, but looking
>> again I only see a 32 bit version uploaded.
>
> So there is a 64-bit version then? It just wasn't posted? I looked on your
> bitbucket project page but it doesn't look like it had any recent changes..
> Is that the most up-to-date place to get the source?
>
> I sent an updated version of Sparkster (with the new sys.path modification)
> to that one tester. He send this back:
>
> C:\Users\Jason\Downloads\Sparkster-Carrie>C:\python27\python main.py
> Traceback (most recent call last):
> File "main.py", line 5, in <module>
> import rabbyt
> File "game\rabbyt\__init__.py", line 35, in <module>
> from rabbyt._rabbyt import *
> ImportError: DLL load failed: %1 is not a valid Win32 application.
>
> So it looks like the 0.8.3 version that I have is still only compatible with
> python 32-bit. What is the issue that is preventing 64-bit compatibility? Is
> it the way a 64-bit cpu handles numbers? That shouldn't be too hard to fix.
> If we can get it working on a 64-bit machine I could include 2 rabbyt
> directories with the project and load the correct one based on their
> architecture and version of python installed.

Rabbyt works fine with 64-bit. The only reason that there's no 64-bit
windows package is that I haven't figured out how to build a python
extension for 64-bit windows. (Notice that there are 64-bit linux
packages.) If anyone want's to figure this out that'd be great.

MWM