Guido van Rossum wrote: > This is another area where API standardization is > important; as soon as modules are loaded out of a zip file, the > traditional approach of looking relative to os.path.dirname(__file__) > no longer works.
Certainly. However, I get two conclusions out of this: 1. don't load packages out of .zip files. It's not that bad if software on the user's disk occupies multiple files, as long as there is a convenient way to get rid of them at once. Many problems go away if you just say no to zipimport. 2. standardize on file names, not API. If I want to deploy read-only data files, I put them into /usr/share. If I need read-write files, I put them into /var. I did not have such a problem yet on other systems, but I would also try to follow the conventions of these systems. With these combined, I can use any API I like to operate on the files. distutils already has support for that. Some libraries (not necessarily in Python) have gone the path of providing a "unified" API for all kinds of file stream access, e.g. in KDE, any tool can open files over many protocols, without the storage being mounted locally. I consider this approach flawed: once I leave the realm of KDE programs, this all stops working. It is the operating system's job to provide unified access to storage, not the programming language's or the job of a library. >> - I still fear that the code of setuptools will turn out to be >> a maintenance nightmare. > > AFAICT Phillip has explicitly promised he will maintain it (or if he > doesn't, I expect that he would gladly do so if you asked). This has > always been sufficient as a "guarantee" that a new module isn't > orphaned. He has, and it is. Still, for whatever reason, I feel particularly uneasy here (and yes, that is my fear, my uncertainty, and my doubt). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com