[Distutils] thoughts on distutils 1 & 2

Bob Ippolito bob at redivi.com
Fri May 14 12:52:53 EDT 2004

On May 14, 2004, at 12:20 PM, Mark W. Alexander wrote:

> On Fri, May 14, 2004 at 03:16:31PM +0100, has wrote:
>> - Reject PEP 262 (installed packages database). Complex, fragile,
>> duplication of information, single point of failure reminiscent of
>> Windows Registry. Exploit the filesystem instead - any info a
>> separate db system would provide should already be available from
>> each module's metadata.
> I agree with rejecting 262 as well, but not in favor of the filesystem
> but in favor of the native platform tools via bdist support. Solaris
> people use pkgtools for everything. RH and friends use RPM. HP people
> use SD-UX. Debianites use dpkg. etc. etc. etc.... God help those of us
> supporting multiple platforms.
> In each case, absent [expletive deleted] commercial package installs,
> all software and configuration management is consistent and, more
> importantly, effective. Anything on top of that; CPAN, Distutils,
> PEP 262, rogue admins with tarballs; _anything_ at all and people who
> have to deal with anything over a handfull of machines WILL eventually
> get caught with their pants down.
> If Distutils does not support simple, native package manager
> integration, then it ceases to be a solution and becomes just one more
> problem. A successfull implementation that creates native packages gets
> immediate support from apt, yum, yast, urpmi, pkg-get, swinstall and
> anything else, now and in the future.

Not all operating systems have a usable package management system 
(Win32, Mac OS X, probably others).

Not all users are superusers and can manipulate the system-wide 

Don't throw the baby out with the bathwater, PEP 262 can be revised 
such that it should cooperate with any existing platform specific 
database when possible and appropriate.


More information about the Distutils-SIG mailing list