How can I get the Panda samples working on my current installations of Python (2.3.5 or 2.4)?
You will need to get the Panda3D source and recompile it against your Python of choice. Another user has recently been down this road; check out the thread here: https://discourse.panda3d.org/viewtopic.php?t=340
Although from reading your other posts, I infer that you are unable to run the Panda samples at all. If your goal is simply to run the sample programs, it may be much simpler to figure out why that is not working–it’s probably just as simple has having a global reference in your environment (for instance, on your PATH variable, or your PYTHONPATH) to the wrong version of Python, so that the shortcuts are picking up the wrong DLL’s.
But if your longer-term goal is to be productive in Python 2.4, or even if you just want some experience building the C++ sources, then by all means proceed with building your own Panda–it’s a useful and rewarding process.
David
I have an existing well-structured Python installation that I want to use (in Windows), so I’m off to build from the source code (after E3, however).
My long term goal is to get Panda to work as a proper Python site-package (which I don’t think the current source build will allow, but we’ll see).
I did manage to get the samples working, I created a panda.pth file that is placed in the site-packages folder:
# .pth file for the Panda3D extensions # The goal of this effort is to make Panda3D a proper python site package # NOT PART OF DEFAULT DISTRIBUTION # Added by Steven Davis, IT GlobalSecure, [secureplay.com/](http://www.secureplay.com/) panda panda\bin panda\lib panda\lib\Py panda\direct\src\showbaseCURRENT PROBLEM, libdtoolconfig and several other dlls in panda\bin are dependent on python22.dll… which
OF COURSE, screws up python24! need to find out how to externalize site-package
I then installed the Panda3D package in the site-packages folder in its own folder called “panda” (if you do something different, change the pth file above). This allows the examples to run. However, Panda3D is not visible to my Python installation and vice versa.
It seems to me that in the long term that Panda should be structured as a site-package and that the version of python should be externalized so that the dll can be set by editing a file.
If the Panda team can get to a site-package installation approach, they can still distribute a standalone version but also one that is friendlier to existing Python users! Then, the Panda installer could easily check if there is an existing installation during its install and use it as a default.
Also, it would be good to know what Python library dependencies Panda has (if any).
Our game security/anti-cheating product, SecurePlay (secureplay.com/), has a Python binding so I am very interested in a free, easy game development environment.
Steve
If you build panda from source, using Python 2.4, you’ll end up with everything using python24.dll instead.
I believe all ppython.exe does is set some variables and then invoke python.exe (albeit from within the panda3d directory tree).
On my system, I pointed the makepanda.py to get python from c:\python24, and it copied from there. I haven’t tried to get it such that panda .py files will “just work” when invoked by the system’s python install, but I don’t see why it couldn’t.
Of course, I’m a python newbie, Panda3d being my entry into learning this language…I definitely do not have a clear understanding of everything you mean in your post, but I do think part of your problems are due to trying to use the distributed panda3d with a different version of python.
I am sure that the clean build will be fine. My comments pertained to the problem in the initial question… if you don’t want to do a clean build, how do you get Panda to work on a machine with Python installed? or, what happens when Python comes out with a new release… recompiling would seem to be a big pain and should be unnecessary (mostly).
The process I described “worked” without doing a rebuild. Not pretty, but functional.
While trying to run down the problems I was having, I reviewed how Panda is set up… as you note, really for a “Pythonless” system - either install as is or recompile. For a lot of potential developers, this is not a good assumption. A lot of people are going to be driven away from a very promising tool by an awkward installation process.
As a developer, I think Panda “should” work like other Panda code packages so that it can be friendly to both existing installations and new ones. At a minimum, the links to the version and location of Python should be settable in a configuration file.
I hope that the Panda team will take this on, otherwise, I plan to work on it (in my copious free time).
Steve
Unfortunately, because of the design of Python, any Python package that is not pure Python code–that is, any package that includes some C/C++ code–must be recompiled for each different version of Python. The distutils scripts perform this compilation automatically, without much input from the user, which works well for simple applications.
But for something of Panda’s size, this compilation step is, as you point out, awkward at best. But the only way we can provide a version of Panda that installs cleanly into any version of Python, without requiring recompilation by the end-user, is to pre-compile Panda for every possible version of Python.
Not completely out of the question, of course, but hardly simple. A better compromise, I think, will be to provide a number of downloads for your version of Python of choice. Still a bit of a logistical challenge.
David
Especially for something of Panda’s size, it would seem worthwhile to do some work to “wrap” the differences between different versions so that a complete rebuild was not necessary (perhaps 1 dll?). Also, by formatting Panda as a site-package, you would be more likely to work with an existing implementation. As it is, the Panda application architecture is really designed for a standalone implementation with no other Python on the machine. If you are going to stay with that approach, you should isolate yourself better from existing installations.
I think that there should be two settings for Panda:
-
A “production” copy for standalone developers and game players. This installation should be designed to completely protect itself from existing Python installations. Basically, this would be a Panda application exe with embedded Python scripting support. The current version is close to this, but not really there.
-
A true “library” version for existing Python users. The real benefit of this would be to keep “mid-level” Python programmers who are not into the C side of things from getting angry about their installation not working. Recompiling is not a friendly answer (especially as it will have to be repeated with each upgrade of Python).
Actually, either approach is OK. In the long term, you need to support both so that it is easier to build and ship a standalone game using Python & Panda while working with a development environment of your choice.
Steve
I agree with your analysis; that sounds like a useful pairing.
Unfortunately, even the “library” version, or at least some portion of it, will have to be recompiled for each version of Python. That’s just the nature of the beast. Every Python module that involves some C/C++ code is version-specific.
Now it’s true that you wouldn’t necessarily have to recompile all of Panda; just the part of it that defines the interface to Python. That’s currently compiled into the DLL’s as the *_igate.cxx files that get compiled in each directory. These could, with some effort, be pulled into a separate DLL that gets recompiled for each new version of Python, but right now the time it takes to compile these files is proabably about 50% of the time it takes to compile all of Panda, so I’m not sure that you really get a lot of bang for the buck there.
David
Actually, most of the time building Panda comprises:
- running interrgogate (I dont know how long exactly, because I never let it ran to completion but at least two hours on my machine
- linking libpanda.dll
I think it would make a much smoother rebuild if the package supplies libpanda.dll prebuilt, and the igate.cxx files pregenerated by interrogate.
Then all you have to do is use distutils to compile the igate.cxx into the Python interface dll, which wraps libpanda.dll, and voila!
I think this would probably run in less than 15 minutes; that’s obviously a guess, but anyway I think it will run much faster than the 3 hours or so it takes for a full build.
Hugh
By the way, let me know of anything I can do to help make this happen.
I think its best if the direction comes from your side, because you are responsible for the actual distributions and so on, but I’m quite happy to do whatever it takes to help put this into production.
I guess the modifications comprise:
- modify makepanda.py to split libpypanda.dll from libpanda.dll
- ensure the files from interrogate are part of the distribution
- create a setup.py file
I’m happy to do the makepanda.py modification, but actually it’s really easy to do. It’s just a question of ensuring the igate object files, and the panda_module object, are not linked into libpanda.dll. The main issue is I dont “own” makepanda.py, and have no way of obtaining the “latest” version. I did submit a makepanda.py patch before, but it seems to have got lost in the void 
The interrogate result files are obviously easy to get hold of, since they’re created automatically by whatever build mechanism you are using. The only thing to do is to copy them into the distribution.
Then there is the setup.py file at the end. This is not that hard to write, it just needs doing. This is probably the bit I can most easily contribute.
If you can supply me with the interrogate-generated files for 1.0.3; and libpanda.dll etc, without the igate files linked in; then I can have a look at writing the setup.py if you want?
Hugh
Frankly, I’m not convinced this is a good idea. Why not just distribute precompiled versions for all the variants of python? Easier, and more reliable.
That works too 
Hugh