[Python-Dev] magic in setuptools (Was: setuptools in the stdlib) (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Thu Apr 20 22:07:06 CEST 2006

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

More information about the Python-Dev mailing list