4
\$\begingroup\$

Background Information

I'm using the python-ogre SDK, located here, under Windows 7. The SDK seems to have its own interface to the python 2.7 interpreter, judging from the fact that the generic interpreter (the one located in C:\python27) must be present in order for the SDK to function.

If the generic python 2.7 interpreter is not installed, the python-ogre interpreter complains that python27.dll is missing.

In addition, modules seem to be highly compartmentalized. The python-ogre modules are only available under the python-ogre interpreter, and not the generic python 2.7 interpreter. The inverse is also true. Modules installed to the generic python installation are not available to the python-ogre SDK interpreter.

I'm not really sure what's going on here, so general clarifications would be helpful.

The Import Problem

I recently installed PyYAML and it imports successfully in the standerd python 2.7 interpreter. However, when I try to import it from the python-ogre SDK's interpreter, I get an ImportError: No module named yaml error.

What gives?

This may be a general python issue, but it does seem to relate directly to the python-ogre SDK.

As usual, I will be happy to provide additional information upon request. Any advice or help would be greatly appreciated!

OK GOT IT!

I just did a sys.path.append('C:\Python27\lib\site-packages'). Apparently all 3rd party modules are installed to this directory.

Is this safe to do? Do I risk creating conflicts between python-ogre and regular ol' python?

\$\endgroup\$
0

2 Answers 2

Reset to default
1
+50
\$\begingroup\$

It's been a while since I used python-ogre, but I grabbed the package you mentioned.

It looks like they've included their own copy of python.exe, but not the python DLL - I'd assume they just never tested their package on a python-free machine before. At first I thought that this was a custom exe linked with Ogre, but it looks like the same file as my standard ptyhon.exe.

It should be safe to use your site-packages, with two caveats:

  1. I would make sure site-packages is in python's path after the python-ogre Lib folder, in case they have any special overrides of other packages. (Which is doubtful, but couldn't hurt.)
  2. Be sure that you add the path not only when you're running your game, but also when calling any packaging application like py2exe - this will allow py2exe to walk your imports and find everything it needs to bundle in your application.
\$\endgroup\$
5
  • \$\begingroup\$ Thank you very much for the clear, actionable advice. I'd also like to thank you for taking the time to install the library to test things out! The bit about py2exe is particularly helpful given that I plan on using this app to package the game. One last question, can I install the python dll manually to the python-ogre SDK installation? I'd like to simplify things by adding the SDKs interpreter to my global variables, such that a call to "python" at the command line will it. That way, I can just remove the stock python27 installation and keep things clean. How can I do this? \$\endgroup\$
    – Louis Thibault
    Commented Feb 4, 2012 at 14:39
  • \$\begingroup\$ Copying the Python DLL next to the executable should work fine, though I didn't try it. Dumpbin reports that python.exe also requires the vc90 runtime libs to be installed, but that's an easier (and more common) package to require users to install. \$\endgroup\$
    – justinian
    Commented Feb 6, 2012 at 21:41
  • \$\begingroup\$ vc90? How strange, considering python-ogre is a cross-platform library. In any case, I shall give it a shot. Thanks again! \$\endgroup\$
    – Louis Thibault
    Commented Feb 6, 2012 at 23:44
  • \$\begingroup\$ It's the windows version of the python interpreter that links against the VC runtime, not necessarily the python-ogre library specifically. Even though python's interpreter is platform-agnostic code, it still gets built against the C runtime from MSVC when it's built on windows. :) \$\endgroup\$
    – justinian
    Commented Feb 7, 2012 at 9:43
  • \$\begingroup\$ Today, I learned! Thanks again. I'm glad you got the bounty =) \$\endgroup\$
    – Louis Thibault
    Commented Feb 7, 2012 at 12:02
0
\$\begingroup\$

I'm not sure about the pyEngine itself but there is one big thing I can tell for sure. using 'C:\Python27\lib\site-packages' is not portable. Think how many of your clients have installed python and PyYAML in exactly in the same folder? to make it portable you have to copy/paste PyYAML files into your game project data, and if needed call sys.path.append with relative address (from your project binary) to data folder.

\$\endgroup\$
1
  • \$\begingroup\$ This is definitely true, too. I'd go so far as to say it's even true when sharing code between developers on the same team. (Some people don't like installing Python in the root of their drive.) Having this in some sort of developer-local config, or putting your external dependencies right in your project is a good idea. But I'd say you shouldn't expect your end-users to have Python installed at all (especially for a game, and on windows) - distributing a package bundled with py2exe/py2app/etc saves you and them a lot of headache. \$\endgroup\$
    – justinian
    Commented Feb 3, 2012 at 1:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .