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).