RetroSearch Browse

Mon Apr 10 03:07:23 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-April/063571.html

At 09:35 AM 4/10/2006 +1000, Andrew Bennetts wrote:
>On Sun, Apr 09, 2006 at 02:48:47PM -0400, Phillip J. Eby wrote:
> > At 07:56 PM 4/9/2006 +0200, Martin v. Löwis wrote:
>[...]
> > >-1. These aren't external libraries; they are part of Python.
> >
> > They *were* external libraries.  Also, many OS vendors nonetheless split
> > the standard library into different system packages, e.g. Debian's
> > longstanding tradition of excising the distutils into a separate 
> python-dev
> > package.
>
>Debian has fixed this bug.

And there was much rejoicing.  :)

> > As much as we might wish that vendors not do these things, they often have
> > practical matters of continuity and documentation to deal with; if they
> > currently have a "python-ctypes" package, for example, they may wish to
> > maintain that even when ctypes is bundled with 2.5.
>
>They can do that just by shipping an empty "python-ctypes" package that 
>depends
>on the full python package.

Yeah, but why do something that logical and simple when you can create 
elaborate patches to remove functionality from setup.py?  ;)

But you've convinced me.  I'd still prefer we generate these packages' 
PKG-INFO from the "formerly external" packages' setup.py files in order to 
ensure the metadata is correct.  But if we have to do it manually, we have 
to do it manually.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-April/063571.html below:

[Python-Dev] need info for externally maintained modules PEP