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

"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