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 think some documentation or a quick exception when the package fails
to load would be sufficient. Wouldn't it make more sense to change
"import_pygame_bufferproxy()" in pygame.h to throw an exception with a
helpful message?
"Required library, pygame.bufferproxy, faliled to import. Check your
pygame installation or try manually include this library."
-Zack
On Feb 5, 2009, at 3:04 PM, Brian Fisher wrote:
On Wed, Feb 4, 2009 at 10:25 PM, <[email protected]> wrote:
Brian Fisher <[email protected]>:
I thinks it's very important that packaging tools work out of the
box with
pygame and have no mysterious failures. If it takes a hack, it takes
a hack.
I think, packaging tools should do their job right and do not behave
wrong.
I agree with that completely. Lets help them by making our package
dependencies more tractable :)
If there are alternatives to the hack, they should be used. But not
solving
the problem is not an alternative.
That's not what I wrote, if you'd have read my mail. I wrote that we
should
fix that on the user-kevel with providing a matching script for
py2exe.
I'm sorry, I didn't mean to misconstrue what you said. The "problem"
I was referring to was py2exe/py2app working "out of the box". I
know you were offering a constructive solution, I just want to solve
a slightly different problem
