It does seem like something fundamental isn’t working here.
First, we should figure out why your module command is failing. This uses Python’s own modulefinder to look for the named modules along sys.path. It works perfectly for me. Is it possible that sys.path is not set up correctly in your case to find the modules you are naming?
Also, note that the ppackage command, and the pdef syntax, is just intended as a convenience for developers who wish to build packages from the command line. If you are writing a Python program, you can use the Packager interface directly from Python; there is no need to use pdef at all. See this thread for a little bit more about this.
The omission of direct.wxwidgets has been previously reported and will be corrected in the future.
Absolute paths are burned into the compiled executable by MSVS, and into the Python binaries by the Python interpreter, at the time the code is generated. That’s unfortunate, and it causes confusion, but usually not any real harm. And it appears to be hard to avoid. (I think there’s a bit more we can do to remove the absolute paths from the Python side, but I don’t know what to do about the paths that the compiler puts in.)
To simulate “-e so” you only need to do:
packager.binaryExtensions.append('so')You can put this at the top of your pdef file, or if you are using the Packager interface directly, you have your own packager object.
I don’t understand why you would want this kind of renaming. The .so extension is important.
I think all of these problems are stemming from the use of the file() command instead of the module() command. This is not the intended way to load Python code, either .py files or .pyd files. The module() command is supposed to work for both kinds of files, and it doesn’t have these weird problems. Really, the file() command is intended to be used to load non-code files, like models and textures.
Are you really running ppackage on Mac OSX in order to build a Windows p3d file? That’s also unexpected. In general, a p3d file is either platform-independent (it contains only pure Python code, no extension modules), in which case it can be built and run on any platform, or it is platform-dependent (it contains some extension modules), in which case it can be built and run only on the target platform. The system is not designed to support cross-building as you appear to be doing; nor is it designed for multi-platform p3d files, p3d files that contain multiple different versions of the same extension modules for different platforms. If you need to achieve multi-platform support like this, you should put the platform-dependent bits into a “package”, and reference it from the p3d file.
But if all of this platform-dependent stuff is only to support wxPython properly, then maybe it’s just on us to fix the “-r wx” package? Or are you using other platform-dependent modules as well?
David