[Python-Dev] [Distutils] Static metadata using setup.cfg

Chris Withers chris at simplistix.co.uk
Tue Sep 8 14:18:56 CEST 2009

David Lyon wrote:
> On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers <chris at simplistix.co.uk>
> wrote:
>> <mini rant>
>> If Python had a packaging system *and* used it for the standard library, 
>> then things like this wouldn't be a problem...
>> The setup.cfg could just say "requires sqlite greater than version 
>> x.y.z", and if it was in the standard library, it would be used unless a 
>> newer version was needed. 
> +1
> Actually, this was already discussed on this mailing list.

Yeah, I know, but I had memories of it be poo-poo'ed on Python-Dev...
(CC'ing so they can tell me I'm wrong ;-) )

> I suggested that a "requires" section could easily do this, something
> along the lines of:
> [Requires]
> stdlib=sqlite>=1.5

Tarek, How are requirements spelled for packages in your current setup.cfg?

I really don't see why anything should be different for standard library 
packages (ie: the stdlib= prefix in David's example). Python 
distributions should just declare all the versions they come with in the 
same way that whatever-is-being-built by Tarek can introspect in the 
same way as any other package...

> So the concept of having an if/else test for this is superfluous.


>> It would also mean it would be possible to 
>> release bug fix versions of the standard library packages without having 
>> to roll a whole python release.
> +1

...which in turn would mean that the standard library is no longer a 
place where packages go to die...

>> Better yet, since "python" should be a package as far as the packaging 
>> system is concerned, library versions can just say what versions of 
>> python they work with.
> +1 - good idea

...and for me, the "python" package should be just another package in 
the distributions dance, called "python" ;-)



Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk

More information about the Python-Dev mailing list