Mike C. Fletcher schrieb:
> One of the posters to my blog posted a little function which allows for
> loading all .egg files in a py2exe distribution directory. The point of
> the code is just to scan a directory (or directories) looking for
> "distributions" and asking pkg_resources to "activate" them. Obviously
> this doesn't help with the question of extracting just the required
> elements from an egg, or detecting and copying a .egg to the
Last night I did a quick hack to py2exe (which is not ready for redistribution)
that will detect that a module or package is in a zipped egg.
It copies this egg file to the distribution directory, and sets up
the executable to add this egg to sys.path. So, it is possible that
py2exe could support this. There are problems, however:
- py2exe does not detect that modules that the code in the
egg itself imports, so you may have to specify these modules
for inclusion into py2exe in some other way.
- Of course, the whole .egg will be copied into the dist directory,
while only parts of it may be needed.
All in all, a quick hack that works but it defeats py2exe's mission.
OTOH, unzipped eggs in Pythons Lib/site-packages directory are picked up
as they should be py2exe; I see no problem here and see this, for now, as
a useable workaround for the missing egg support in py2exe.
> distribution directory, but it should allow for a straightforward recipe
> for (functional, if not elegant) egg support:
> # exclude your .egg-derived packages from the py2exe gathering
> # copy the .egg files/directories over to the distribution directory
> # then in your script (somewhere)...
> import py2exeeggs
> At least, that's the theory. I don't have a windows machine handy to
> test the slightly-refactored version, but it's available here for those
> who may have such a machine:
> Obviously that's not the right spot for such code. It should (or
> something like it should) likely be in the py2exe project, since it's
> more generally useful than PyOpenGL projects (once it's debugged and
> working reliably).
Well, the question is if we need or want such code at all. I have always
been careful to not let py2exe add any directories to sys.path so that
the resulting exe should be somewhat robust against additional files copied
into the exe directory; usually only library.zip is on sys.path, and library.zip
even contains loaders that will only load those .pyd files that the build process
PyOpenGL2 has a history of not being compatible with py2exe except when it lives
in the file system. IIRC, that was because PyOpenGL2 contained a lot of __init__.pyd
files that py2exe would have copied all into the dist directory, one overwriting the
other. I'm not sure I got this correctly.
PyOpenGL3 seems to continue this history ;-), although probably for a different reason.
When I tried to build an exe from the dots.py script, it went like this:
- First, I had to unzip the setuptools egg in Lib/site-packages. This was probably
because of the missing zipped egg support in py2exe.
- PyOpenGL is installed as unzipped egg, so it does not seem to be a problem.
Building with a trivial setup script went fine, but the resulting exe does not
run (I added 'import logging; logging.basicConfig(level=logging.DEBUG)' to dots.py).
I get the same error that some user reported to the PyOpenGL-users mailing list:
INFO:OpenGL.GLUT.special:Using NT-specific GLUT calls with exit callbacks
Use the mouse buttons to control some of the dots.
Hit any key to quit.
WARNING:OpenGL.arrays.arraydatatype:Failure on asArray: Traceback (most recent call last):
File "OpenGL\logs.pyc", line 39, in loggedFunction
File "OpenGL\arrays\arraydatatype.pyc", line 60, in asArray
File "OpenGL\arrays\arraydatatype.pyc", line 35, in getHandler
TypeError: No array-type handler for type <type 'numpy.ndarray'> (value: array([[ 0.50522523, -0.99075463],
GLUT callback forcing low-level exit on error: No array-type handler for type <type 'numpy.ndarray'> (value: array([[ 0.
Ok, so add this line at the top of dots.py:
sys.path.insert(0, os.path.join(sys.prefix, "PyOpenGL-3.0.0a5-py2.5.egg"))
Build the exe excluding PyOpenGL, and specify required modules manually:
setup.py py2exe -e OpenGL -i ctypes,ctypes.util,weakref
then I xcopy the PyOpenGL egg directory into the dist folder, and the exe works.
I'm not sure why this is so, how and when are the array-type handlers registered?
Is this a problem of PyOpenGL?
PyOpenGL uses pkg_resources somewhere, does pkg_resources work inside zipped
modules (that are not eggs)? Does it need some of the egg-info files that
are normally included with a egg?
> Anyway, hope this is a useful contribution to the discussion,
Before some real egg support is added to py2exe, the requirements should
be specified. Should py2exe search inside zipped eggs for imports?
Should it pull the zipped egg apart, and include only the parts that are needed?
Both requirements could be fulfilled easily if py2exe did unzip the egg(s)
to a temporary directly, and add this to the sys.path used while building.
So maybe this would not even be too complicated.