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

Ronald Oussoren ronaldoussoren at mac.com
Fri Apr 21 08:00:04 CEST 2006


On 20-apr-2006, at 23:08, Martin v. Löwis wrote:

> Ronald Oussoren wrote:
>> As far as I understand the issues they compete up to a point, but  
>> should
>> also make it easier to create platform packages that contain  
>> proper the
>> proper dependencies because those are part of machine-readable  
>> meta-data
>> instead of being written down in readme files. Oddly enough that was
>> also the objection from one linux distribution maintainer: somehow  
>> his
>> opinion was that the author of a package couldn't possibly know the
>> right depedencies for it.
>
> What he can't possibly know is the *name* of the package he depends  
> on.
> For example, a distutils package might be called 'setuptools', so
> developers of additional packages might depend on 'setuptools'.  
> However,
> on Debian, the dependency should be different: The package should  
> depend
> on either 'python-setuptools' or 'python2.3-setuptools', depending
> on details which are off-topic here.

But when the dependency is written down the platform maintainer, such as
the Debian developers, could create a mapping from distutils package  
names
to platform package names. And this could be done using rules instead of
a mapping tape (e.g. the platform package is 'python%(pythonver)-% 
(distutilsname)').

The important bit is that dependencies a present in a machine  
readable form, and
thanks to easy_install you can be pretty sure that these are actually  
useable.

>
>> As for platform packages: not all platforms have useable packaging  
>> systems.
>> MacOSX is one example of those, the system packager is an  
>> installer and
>> doesn't include an uninstaller. Eggs make it a lot easier to  
>> manage python
>> software in such an environment (and please don't point me to Fink or
>> DarwinPorts on OSX, those have serious problems of their own).
>
> Isn't uninstallation just a matter of deleting a directory? If I know
> that I want to uninstall the Python package 'foo', I just delete
> its directory. Now, with setuptools, I might have multiple versions
> installed, so I have to chose (in Finder) which of them I want to
> delete.

Not always. Several distutils packages install multiple toplevel modules
or packages and the names of those aren't always obvious. If they'd use
extra_path I could still remove a directory and .pth file, but that  
option
isn't used a lot.

>
> That doesn't require Eggs to be single-file zipfiles; deleting
> a directory would work just as will (and I believe it will work
> with ez_install, too).

Egg directories (which are basically just the same as packages  
using .pth files)
also work for this and that's what I usually install. Setuptools can  
work
with python extension inside .zip files, but I'm not entirely  
comfortable with
that.

>
>>> Package
>>> authors will refuse to produce them, putting the burden of package
>>> maintenance (what packages are installed, what are their  
>>> dependencies,
>>> when should I remove a package) onto the the end user/system
>>> administrator.
>>
>> Philip has added specific support for them: it is possible to install
>> packages in the tradition way but with some additional files that  
>> tell
>> setuptools about installed packages.
>
> As a system administrator, I don't *want* to learn how to install
> Python packages. I know how to install RPMs (or MSIs, or whatever
> system I manage); this should be good enough. If "this Python junk"
> comes with its own installer procedure, I will hate it.

But setuptools doesn't make it impossible to use system packages.  As  
long
as those system packages also install the EGG-INFO files packages  
that make
full use of setuptools will be happy as well.

I agree about system packages when I'm in my system administrator role,
but when I'm in my developer role it would be very convenient to have  
cross-platform
tools that enable me to quickly install software and tell me what  
I've got installed.

Ronald



More information about the Python-Dev mailing list