[Catalog-sig] PyCon sprint for PEPs 314 and 243?
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
> 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
> 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
> Module Repository Upload Mechanism
> Database of Installed Python Packages
> I'd want to revise PEP 243 at some stage. I want to *only* implement
> distribution uploading for now. Also, there's some aspects of the
> that need work (eg. we should use standard HTTP responses, not
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