[Catalog-sig] Back to RPC

[Ian Bicking]

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  /  ianb at colorstudy.com  / http://blog.ianbicking.org