[Catalog-sig] Re: [chiPy] Meeting followup- CPAN for Python?
ianb at colorstudy.com
Wed Dec 15 21:04:31 CET 2004
A.M. Kuchling wrote:
> On Fri, Dec 10, 2004 at 12:51:01PM -0600, Ian Bicking wrote:
>>* Add a field for source download; maybe make it a dictionary, so you
>>can give several links for different sources (e.g., source
>>tarball/zip, rpm, windows installer, debian package, etc).
> An up-and-coming standard for info about packages is an RDF vocabulary
> called DOAP: http://usefulinc.com/doap . IMHO we should think about
> harmonizing the Distutils-supported metadata with DOAP. I've
> submitted a crude patch to PyPI that generates DOAP data for projects.
> Things in DOAP not in Distutils/PyPI:
> CVS/SVN/BK repository (+ anonymous root, module name)
> Mailing lists
> Wiki URL
> Bug database
> Screenshot URL
> Date project was created
Like multiple released branches, or historical releases?
> Versions are a revision number (1.2.3, 1.0a1, etc.) plus
> name and date.
> Multiple language literals (e.g. give both an English and a
> French description).
> However, just adding keywords to setup.core() for all these things may
> not be a good idea -- if DOAP adds new features, we need to add
> support for them. Perhaps there should be some third-party way of
> constructing a DOAP file, after which you'd leave the metadata out of
> the setup.core() invocation.
I'd like this anyway -- it feels distracting that setup.py contains both
metadata for PyPI, and control data for distutils. There's some
intersection, but most of the data really belongs to one or the other.
I'm heavily drawn to using source to represent data, but despite that I
think a static file would be appropriate for most of these descriptions.
Or maybe a feature to setup() that reads metadata from a static file
(so you could generate the data in other ways if you really wanted,
e.g., an analogous .ini file).
> OTOH, requiring an RDF parser to deal with the metadata is also nasty;
> parsers are pretty large, and adding one to the core might be a
Is an RDF parser very complicated? It's mostly just XML with namespaces
isn't it? Do the standard library's XML parsers handle namespaces well?
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Catalog-sig