Martin v. L�wis wrote: > Ian Bicking wrote: > >>Oh, sure, I guess I can do that. Does the PEP process really add much >>here, or would a document be sufficient? > > > It might be sufficient, provided it contains the same information that > a PEP contains. I.e. I would like to see a problem statement, and > a discussion of alternatives (based on the feedback that you get for > the initial document).
Sure, I'll try to do that. But like I said, it's something I'd like to use very soon, and I was actually in the middle of implementing it separately when I realized that it was closer to the scope of PyPI than I at first thought. I'd at least like to have a read-only devel copy of this stuff that I could experiment with. If it's in a branch or whatever, that's fine. If I have to host my own copy of PyPI for a while as we discuss the additions that'd even be fine. Whatever -- I just want to move forward on this, and discuss the good and bad of specific code; if it means I write code that's thrown away, that doesn't really bother me. OTOH, there's a lot of purely internal refactorings to PyPI that would make many of these things easier while also making PyPI easier to maintain, and forking PyPI to do apply those would be a total waste. > I find that your initial draft describes a very complex system, and > I'm concerned that it is too complex for most users. It seems to > be similar to the SF file release system (requiring me to describe > all sorts of meta-information with choices from a set of options > that don't help to describe *my* package), so I wonder whether this > change would make PyPI less usable. I don't see many added complexities at all. It comes down to a couple of things: * Document what packagetype's are. Pretty much a no-brainer; what can be wrong about documentation? * I think those types should include svn-trunk. I can spell out use cases if people like -- they have a lot to do with interdependent packages that track each other's changes, and making that more usable for package users. * Some public XML-RPC methods. I think the ones I spelled out are pretty obvious; not necessarily complete, but a proper start. * Some resolution process for updating and correcting metadata, probably just starting with a contact form. This is primarily about PyPI-the-webapp, which doesn't really need to be that formalized (compared to PyPI-the-package-database). packagetype already exists. I don't know what the interface is to set it, but it's there in the database. I haven't proposed any new fields (though an optional "title" field for package URLs might be nice, kind of like a title field to <link> tags). And I don't think SF is a good example of anything. I can't imagine a worse designed user interface. So it's not fair to use that as a counter argument to anything ;) -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Catalog-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
