On Jul 8, 2006, at 9:26 AM, [EMAIL PROTECTED] wrote: >> Jim Fulton <[EMAIL PROTECTED]> wrote: >> Don't feel bad, I have trouble following this too. :/ > > Great, Johannes (who is next to me and in a similar state of mind) > and I feel much better now :) > > >>> I have created a branch for this and have begun the slow process of >>> working in the setuptools name mangling. It's going to take some >>> time since package names are used all over the place and form an >>> integral part of the database referential structure. >> >> IMO, no one should be writing code at this point. I think we should >> slow down, decide on and carefully document an API before we do any >> more coding. (Where "we" mostly refers to you and Phillip. :) > > My position on all this is that: > > 1. PyPI is the central index for metadata about python packages. I > am not aware of any other such indexes, nor am I aware of an > intention to create one. I would not be in favour of doing so, > since it would fragment the community.
I am mostly concerned that we have a well-defined API, however, I think there is a potential place for other indexes. There are all sorts of reasons one might not want or be able to put software in PyPI. For example, an organization may have proprietary information that they can't put in PyPI. They should be able to run their own index. This would not be quire so important if setuptools provides an option to not look in an index or, if having found packages via find-links, it was willing to not look at an index. > 2. I'm not particularly interested in developing APIs for PyPI I'm gomma interpret this as meaning that you don't want to have to develop (define) an API yourself, but you would be happy if there was an API. I hope I'm right. > though I am happy to add in XML-RPC functions as needed since > they're trivial to write. So you are unconcerned by the use case for static indexes? Or static mirrors of indexes? Do you really want to prevent such a use case from being met? > 3. I would really like to see an emphasis on moving away from > scraping HTML since the HTML is changed for *cosmetic* reasons. If > need be we can produce "static" XML (like the DOAP) to go alongside > it which will not change the next time the pydotorg layout is changed. I think everyone agrees with you. I think screen scraping was a valuable expedient when setuptools was being prototyped, but it's time to move beyond that. Obviously, we have to agree what to do, but that means an API. > 4. Patches, and additional svn committers, are always welcome. I'd be willing to help out once we agree *clearly* what we're doing. That means, among other things, an API. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Catalog-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
