[Catalog-sig] Back to RPC
ianb at colorstudy.com
Mon May 23 08:29:59 CEST 2005
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
* 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 / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Catalog-sig