[Catalog-sig] PyCon sprint for PEPs 314 and 243?

Bob Ippolito bob at redivi.com
Fri Dec 31 10:48:10 CET 2004

On Dec 29, 2004, at 11:35 PM, Richard Jones wrote:

> So, is anyone interested in getting together before PyCon for a sprint 
> to
> finalise and/or implement PEPs 314, 243 (I guess we should ask for 
> some PSF
> money, though we've obviously missed the most recent grant allocation 
> round)
> and possibly 262 (I consider this optional and don't believe it should 
> get in
> the way of implementing the other two)?
> Metadata for Python Software Packages v1.1
>   http://python.org/peps/pep-0314.html
> Module Repository Upload Mechanism
>   http://python.org/peps/pep-0243.html
> Database of Installed Python Packages
>   http://python.org/peps/pep-0262.html
> I'd want to revise PEP 243 at some stage. I want to *only* implement 
> source
> distribution uploading for now. Also, there's some aspects of the 
> protocol
> that need work (eg. we should use standard HTTP responses, not
> X-Swalow-Status).

I'm interested in helping this along.  Similar to your revisions with 
PEP-243, here's what I think should happen to PEP 314:

- It should be required to list every "top-level" package/module that 
is installed as Provides fields (else distutils will do it for you).  
"top-level" isn't absolute, as there will be cases like zope.interface. 
  By top-level I mean the highest level that is to be installed by this 
- Every Provides must provide their own version (for Requires), 
distutils will default these to the global version if not explicitly 
- Requires should not be arbitrary.  They should be exactly Python 
module names.   It just gets too messy otherwise.  Having such a 
meta-requirement is completely and utterly useless without also having 
PEP-262 implemented and accessible at runtime.  If you say that a 
package requires *some* DBI API 2.0 driver, how would you find one?  In 
order to support this sort of use case, it might be worthwhile to have 
a way to say Requires "foo (>1.0) OR bar (>1.2)" (say a package that's 
compatible with PEAK or Twisted, but needs one or the other).


More information about the Catalog-sig mailing list