Im unable to to freeze the Pmw module, how do Panda3d tools do it?
Nice tutorial you have there, although I’m missing arguments contra the usual panda way. (You only say you don’t like it)
The lack of answers is probably caused by the suspicious looking “link with an exe in it”.
Is there a reason you release this as PDF and not as a simple forum text?
Anyway, a short introduction or description on the PDF might get you more response.
Have a nice day.
I think the main reason for me is that I can use a single method for distributing my Python programs, both panda and non-panda. But also the official tools have some issues and I don’t see a point in going the p3d way: putting your game in a p3d, then using another tool to make your exe, it’s just not convenient unless you want to make a web application. As for packpanda, it’s deprecated as I see, so there’s no hope in bugfixes and updates, the main issue though is that it doesn’t generate a launcher exe (only shortcut for the main.pyc), so it’s not that easy to make an archive distribution (even that left aside it’s still less convenient: install your own game just to copy files to an archive). For installers thuough i think packpanda is a simpler option than doing all this by hand.
I understand your concern, although the approach that pdeploy uses does allow it to create installers for every platform, without even having to be on that platform.
To be honest I don’t consider this as a real problem. Every team that uses Panda has a programmer, and every programmer can write a small script which joins packp3d and pdeploy (if they want that really). Moreover, almost every project is built by a build-system (like SCons, CMake, …), so you’ll never invoke packp3d and pdeploy manually (i.e. tipically you already have that script which joins them), so I don’t see this breaking down as a problem in a real context. Vice versa, I see this as a great advantage, because you get a platform-independent package (p3d) before in the process and you get the platform-specific stuff only at the end of the build pipeline if you haven’t platform-specific code (this can be exploited in several ways, depending on your build pipeline, your testing strategies, …).
Anyway I don’t want to criticize your approach (I only wanted to highlight that point since I consider it “weak”), it’s a lower-level approach (so it has its pros and cons), it’s a contribution and somebody could find it useful, so thank you! 