[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] py2exe on fonty.py fails with segfault

On Jan 10, 2004, at 4:56 PM, Rene Dudfield wrote:


Bob Ippolito wrote:


On Jan 9, 2004, at 9:06 PM, Pete Shinners wrote:


J. Michael McGarrah wrote:
Adding the default TTF file fixed it. It has to be in the same location as the EXE like you both said.

Excellent! Now I need to make the error in this case a little more reasonable.
Pete, what do you think about coming up with a smarter scheme for resource acquisition?

In the case of Mac OS X (with bundlebuilder), I'd like to be able to override where pygame looks for the ttf file. By default bundlebuilder uses the zip import hook, so __file__ of the module isn't going to be a good place to try and open a ttf file at :) I'd like to shorten the bundlebuilder command line for pygame based applications significantly. I've written (unreleased) tools and a revised version of bundlebuilder that walks all of the extensions for non-system shared libraries and frameworks, then relocates their mach-o headers so it can stuff them into the app bundle. All that I have left is this pesky "--package=pygame" command line argument due to these necessary data files. Other than that "bundlebuilder2 --standalone mypygameapp.py" does all the necessary magic to make a standalone application!

In any case, I'm thinking that such a resource acquisition module should expose a simple API along the lines of:

import resfinder
myfilename = resfinder.fileInPackage('pygame', 'something.ttf')

and perhaps even
myfilelikeobj = resfinder.fileobjInPackage('pygame', 'somedatafile')

if an actual on-disk file is not necessary. This would be useful in the case of py2exe, where the data would have to go in the exe somewhere (perhaps zipped or some such).. a file-like object could be created that accesses 'somedatafile' directly without decompressing the whole thing to a temp folder. At worst case it would do the copy, but on __del__ or close it could clean up.

When using this theoretical resfinder module, you should have some kind of manifest that sits in your package somewhere that lists the non-python-code files that are necessary for correct operation. Future versions of "freeze" applications would know about resfinder and its manifest files and make provisions to (a) put the required data files somewhere (b) throw a manifest file or bootstrap code somewhere such that resfinder is aware of where and how it should acquire these data files. A distutils extension could be developed to generate resfinder manifest files at setup.py time.

I have not done any research to see if a module like this already exists.
Distutils allready has support for extra data files in modules:
http://www.python.org/doc/current/dist/setup- script.html#SECTION000350000000000000000

Maybe that can do what you are talking about.
Thanks for the tip, but no, the issues this theoretical "resfinder" module would solve is entirely separate from distutils. It's a standalone executable packaging issue which ends up being two issues:

[ external metadata issue ]
(1) Python packages don't carry around enough metadata to be accurately packaged up (does a package have necessary data files, or are those just help files?). Right now bundlebuilder actually examines bytecode for imports and does resolution on the module level that way. It will not find data files. py2exe may or may not work the same way, I have no idea.

[ package runtime issue ]
(2) Modules packaged up using an import hook can't find their data files, because they typically use __file__, which may not actually point to something on the filesystem. It may be preferable to put data files somewhere else, and using a convention such as "resfinder" is the only way to do this extensibly.

#2 is the real problem, #1 could be worked around.

-bob

Attachment: smime.p7s
Description: application/pkcs7-signature