[Solved]packp3d custom packages __init__.py not called?

Hi all,

first of I would like to say that the distribution system of Panda3D is really cool.
Inspired by markjacksonguy’s postings about it I started fiddling around with it.

I’ve made a ‘simple’ test app:
The directory structure is as follows:


import sys

from ctypes import windll
from codebase.fibo import *

def main(arg):
    print("Hello World")
    print(windll.user32.MessageBoxA(None, "MessageBox Text", "MyBox", 0))
    # windll.user32


print('__name__=', __name__, '__package__=', __package__)


# Fibonacci numbers module

def fib(n):    # write Fibonacci series up to n
    a, b = 0, 1
    while b < n:
        print b,
        a, b = b, a+b

def fib2(n): # return Fibonacci series up to n
    result = []
    a, b = 0, 1
    while b < n:
        a, b = b, a+b
    return result

For some reason the print statement doesn’t get called and if I look into the p3d with multify -tvf myapp.p3d I see that an init directory was created.

        656   43%    Jun 11 18:52 HelloWorld.pyo
         95   31%    Jun 11 18:52 codebase/__init__.pyo
        225   25%    Jun 11 18:52 codebase/__init__/__init__.pyo
        681   52%    Jun 11 18:52 codebase/fibo.pyo
        383          Jun 11 18:52 p3d_info.xml

Why is that? I guess I miss something about python packages … :neutral_face:

If I run the HelloWorld.py directly the print statement works fine.

Greetings and thanks!

I used morepy etc and the call to MessageBoxA(None, “MessageBox Text”, “MyBox”, 0) works fine - I also don’t see anything wrong in the panda3d logs.

It’s just that the init.py for some reason will not work. :confused:
HelloApp.7z (591 Bytes)

This appears to be a bug in the way packp3d scans the directory looking for .py files. I’ll see about putting in a fix, but in the meantime, an easy workaround in this case is to add something like ‘-d x’ to the packp3d command line (naming a non-existent directory, or at least a directory that doesn’t contain python files), so that it only includes the files that are explicitly imported by HelloWorld.py or by one of the files it imports. Another workaround would be to create a pdef file that explicitly names the files to be loaded instead of scanning with a dir() command.


That did the trick, thank you David! I just had to move the HelloWorld.py out of the HelloApp directory .

Another question.
I saw that direct/p3d/Packager.py uses ‘dumpbin /dependents “%s” >"%s"’ in __addImplicitDependenciesWindowss. Does that mean that I need to have VC9 (Express etc.) installed and setup so that it can find dumpbin and that packp3d etc need to be run in a Visual Studio 2008 Command Prompt? If so I would add that part to the Manual page if thats ok.


That’s only used when your .p3d file contains .dll files and is marked as a per-platform package (which most won’t, since that defeats the purpose of having a cross-platform p3d to begin with). Packager uses dumpbin to figure out which .dll files that your included .dll file depends on, so that it can package those along. (It also uses mt.exe to extract the manifest file so that it can figure out its dependent SxS assemblies.)

But yes, if your intent is to make platform-specific packages that contain .dll, .exe or .pyd files, then you need to have dumpbin.exe and mt.exe available. We may replace it with a binary parser at some point (as we also parse ELF binaries ourselves on Linux) but the need for that has not become apparent yet.

The short answer is that unless you want to package a binary module, you don’t need to worry about it.

Ok, thanks rdb! That is good enough. :slight_smile: