Brian Fisher wrote:
On Thu, Feb 5, 2009 at 12:21 PM, Zack Schilling
<[email protected] <mailto:[email protected]>> wrote:
I don't think manually including bufferproxy when it might not be
needed is a good solution, nor do I think getting py2exe to search
for compiled C modules calling other compiled C modules is likely
to happen.
I agree that dependencies should not be added - but "import pygame"
already tries to import pygame.surface and pygame.mixer, and those 2
modules depend on bufferproxy (and always try to import it)
so given that pygame has always included surface and mixer and those 2
always import bufferproxy (if available) then pygame is already always
importing bufferproxy - whether it is "needed" or not.
So added an in python import of the module really doesn't change
anything other than making py2exe and py2app work out of the box.
.. not that things couldn't be better though. My point is just that
the hack fix here doesn't make anything worse.
Why don't we just have a pygame module called everything. It has top
level import statements of all pygame modules and major dependencies,
such as NumPy and OpenGL, but is not itself imported by __init__.py.
That way a game packaged with py2exe/py2app can just import
pygame.everything and be sure no modules are overlooked. The everything
module could even be copied into a game and pruned.
Included in the pygame distribution directory is an experimental
program, check_test.py, that tracks Pygame modules that are imported and
accessed by a running unit test. It can be generalized to run a game. So
one would see what a game needs, and what can be omitted. And it could
generate a game specific pygame everything module.
--
Lenard Lindstrom
<[email protected]>
