Hi Marcus,Fortunately, from what I can gather, py2exe doesn't actually need a module imported to include it. All it looks for are import statements in the source. It's not necessary for the statement to actually execute. You can see at the bottom of __init__.py:
def packager_imports(): """ Some additional things that py2app/py2exe will want to see """ import Numeric import numpy import OpenGL.GL import pygame.macosx import pygame.mac_scrapThe function is never called. I would see other stuff go there as well, the rwobject and surflock imports at the top of __init__.py and the bufferproxy import as well. But it's a moot point as rwobject, surflock and bufferproxy become a part of the pygame namespace anyway when surface is loaded. As to why I added the bufferproxy import, that's to ensure an exception is raised if it is missing. It's an interim solution as the surface or mixer modules should actually do the check.
I personally don't use py2app/py2exe, though many people do. If some universal manifest protocol exists that all executable builders recognize, that would be great. But probably not. So adding dummy imports to __init__.py seems to be the most practical solution for now.
Lenard mva@xxxxxxxxxxxx wrote:
Lenard Lindstrom <len-l@xxxxxxxxx>: [Hacks for broken py2exe/py2app] Does it make sense, that we touch the whole module initialisation process, because some third party build scripts do not do their job right? Personally I'd vote for some py2exe template that includes all important pygame modules. This can be used by anyone then without the need to pollute the whole application namespace with the pygame modules. Regards Marcus
-- Lenard Lindstrom <len-l@xxxxxxxxx>