On 22-feb-04, at 3:14, Bob Ippolito wrote:
Stuff you should avoid if possible are:
runtime additions to sys.path
intermingling of code and data (keep them in separate folders,
please)
using __file__ or similar mechanisms to find data (really a subissue
of the previous)
For the latter two we should invent something to help people. I know
it should be a general Python solution, but as none seems to be
forthcoming (lots of people have been asking about a way to access
data files, and the party line still seem to be "put them in your
package", even though that breaks with py2exe and zip imports and
such) we should roll our own, I think.
We already have a working example in macresource, which solves a
similar problem (finding a resource file, if the resources don't
happen to be in the resource fork of the current executable already).
For opening data files the API would have to be something different,
probably along the lines of filename =
datafile.datafilename("mydatafile.txt", "mymodule"), where
mydatafile.txt is first looked up in a directory specifically for
datafiles (where it would be found if the program was run as a .app
bundle), then in the same directory as mymodule.__file__.
For OSX bundles the datafile-directory specified above would be
Contents/Resources, and people on other platforms using py2exe or
somesuch are free to tag on to the scheme and invent their own magic
location:-)
I agree completely, but it will also need some sort of manifest file so
that bundlebuilder and py2exe know what data files are necessary. A
future version of distutils should do this (package receipt with enough
metadata to determine what data is essential, and what data is just
examples, tests, help files). There's also the very real problem of
getting package authors to change the way they're currently doing
things, especially the ones with freakish distutils extensions like
SciPy. This isn't a real problem for pygame though, since I maintain
the OS X port and have commit access.