From python at jwp.name Fri Feb 1 00:18:49 2008 From: python at jwp.name (James William Pye) Date: Thu, 31 Jan 2008 16:18:49 -0700 Subject: [Catalog-sig] Adding package pydoc to PyPI In-Reply-To: <47A22D68.3040707@v.loewis.de> References: <20080131162523.GA50793@lit.jwp.name> <47A209DC.5060200@v.loewis.de> <20080131194445.GA51222@lit.jwp.name> <47A22D68.3040707@v.loewis.de> Message-ID: <20080131231849.GA52682@lit.jwp.name> Ok. First. Thank you for giving this message some of your attention. I really do appreciate the discussion. On Thu, Jan 31, 2008 at 09:19:52PM +0100, "Martin v. L?wis" wrote: >> However, it seems poor to pack all the information onto one page. Not to >> mention, I don't think distutils/setuptools has a command to render the >> long_description to contain the pydoc of the package--granted this is >> something for distutils/setuptools, not PyPI. > > Ah, so you want multiple pages per package. ugh, Yes.... > Why? Shouldn't you have some separate home page for the package, then? Considering that I'm suggesting a place to publish the pydoc output of the modules within the package, no, not really. I'll get into why. See the example below describing the mysterious "inter-package references". > PyPI is just the package *index*, not a general project hosting service. But it's okay for a maintainer to use the long_description as a place to publish documentation?... > As for generating a long_description - that's something that setup.py > could do; no need to integrate this into distutils (unless there is > a strong demand that a certain algorithm to include long_description > gets included). The parenthesized portion is kinda getting warmer. =) The pydoc of all modules in the package... >> 1. Can I make inter-package references to specific objects in others packages >> that won't break if PyPI were to change in some way using reST alone? > > I don't understand the question. What's an "inter-package reference"? > What's a "specific object"? Give examples. Sure. I think it would be most illuminating to give an example of what I would *like* to see. Perhaps reST + can do this to a certain degree already. In this example we have two packages A and B. B depends on package A for a class. A has a module m1 and B has a module m2. Module m1 has the class c1, and module m2 has class c2. c2 is a subclass of c1. (class `c1` is an example of a "specific object"). Now, rather than running epydoc or pydoc and publishing the pydoc of my modules and all their dependencies for completeness on my project's host. I run an imaginary "dist_doc" distutils command that extracts the doc-strings and the module structure/hierarchy from my package. I then run "upload" to upload the XML'ified doc-strings produced by "dist_doc" to PyPI in addition to my sdist'd or bdist_egg'd package data. The XML will describe the package's content and attribute the doc-strings to the appropriate objects. Now, the difference. When class c2 is described, it will reference c1, c2 being a subclass of c1. However, it will not include c1's doc-strings. No sir. It will reference c1 by c1's package and path, "A:m1.c1" or whatever. So, this allows PyPI to dynamically construct links to the pydoc documentation of other packages' objects so long as they remembered to upload the dist_doc(perhaps making it a requirement would be a better solution). And most importantly, this will provide consistency and convenience for module authors and users to enjoy as they *know* where to *quickly* find a package's pydocs. >> 3. It would simply be nice to have a dedicated part of the package's place on >> PyPI specifically designed for displaying the package's module hierarchy and >> contents with the associated doc-strings. > > Ok, so you do want a project hosting service. No. That's not what I'm asking for. I want an extension to PyPI to provide a place for module developers to publish the *pydocs* of their package in a structured fashion(ie, not the long_description). Nothing more. I don't want an SCM. I don't want *arbitrary* webspace. I don't want shell access. I just want a user-friendly, standard place to publish the pydocs of my package's modules. (Oh, and I want to read other package's pydocs as well! =) > I don't think PyPI should > provide that, or else people soon find out what a nice file sharing > platform it is, and start uploading adult content, integrate it into > link farms, and so on. I wasn't suggesting any of the material that would be uploaded would be unchecked. As a matter of fact, I was envisioning a single XML document that would be checked against a DTD. Oh, and reST could still be used. =) reST in doc-strings can be made perty just like it is in the long_description. - I do understand the perspective that this is beyond the scope of PyPI, and I respect it. However, as a user of PyPI(almost ten modules, I think), this is something that would be useful to me and, I believe, others, something that I would be willing to implement, and something that seems like a very natural extension for it(PyPI) and distutils. From martin at v.loewis.de Fri Feb 1 06:24:46 2008 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Fri, 01 Feb 2008 06:24:46 +0100 Subject: [Catalog-sig] Adding package pydoc to PyPI In-Reply-To: <20080131231849.GA52682@lit.jwp.name> References: <20080131162523.GA50793@lit.jwp.name> <47A209DC.5060200@v.loewis.de> <20080131194445.GA51222@lit.jwp.name> <47A22D68.3040707@v.loewis.de> <20080131231849.GA52682@lit.jwp.name> Message-ID: <47A2AD1E.4020700@v.loewis.de> >> PyPI is just the package *index*, not a general project hosting service. > > But it's okay for a maintainer to use the long_description as a place to publish > documentation?... The full documentation? That's probably abuse, but we have no resources to screen the packages for that, so that use is tolerated (for now, until people start complaining). >> As for generating a long_description - that's something that setup.py >> could do; no need to integrate this into distutils (unless there is >> a strong demand that a certain algorithm to include long_description >> gets included). > > The parenthesized portion is kinda getting warmer. =) > The pydoc of all modules in the package... A warning, though: a request by a single user can never be strong demand. > The XML will describe the package's content and attribute the doc-strings to the > appropriate objects. Now, the difference. When class c2 is described, it will > reference c1, c2 being a subclass of c1. However, it will not include c1's > doc-strings. No sir. It will reference c1 by c1's package and path, "A:m1.c1" or > whatever. So, this allows PyPI to dynamically construct links to the > pydoc documentation of other packages' objects so long as they remembered to > upload the dist_doc(perhaps making it a requirement would be a better solution). > And most importantly, this will provide consistency and convenience for module > authors and users to enjoy as they *know* where to *quickly* find a package's > pydocs. Ok. See above - I would now think that's abuse of PyPI; you should find a different place for the package documentation on the net (whether single-paged or multi-paged), and then use standard HTML linking for these cross-references. >>> 3. It would simply be nice to have a dedicated part of the package's place on >>> PyPI specifically designed for displaying the package's module hierarchy and >>> contents with the associated doc-strings. >> Ok, so you do want a project hosting service. > > No. That's not what I'm asking for. I want an extension to PyPI to provide a > place for module developers to publish the *pydocs* of their package in a > structured fashion(ie, not the long_description). Nothing more. See, that's already asking too much, IMO. To me, that's clearly out of scope for PyPI. > I don't want > an SCM. I don't want *arbitrary* webspace. I don't want shell access. I just > want a user-friendly, standard place to publish the pydocs of my package's > modules. (Oh, and I want to read other package's pydocs as well! =) If you think there is demand for such a service (publishing pydoc only), feel free to offer it to the community. I don't see the need for such a service to be centralized, and you might actually be able to implement it even for packages that don't actively use it, by extracting such pydoc pages from any new package that gets uploaded. > I do understand the perspective that this is beyond the scope of PyPI, and I > respect it. However, as a user of PyPI(almost ten modules, I think), this is > something that would be useful to me and, I believe, others, something that I > would be willing to implement, and something that seems like a very natural > extension for it(PyPI) and distutils. See above. If you implement the service, I would consider it feasible to provide a link to a package's pydoc documentation in PyPI (similar to homepage and download_url; say documentation_url), although support for that in distutils probably requires a PEP. Regards, Martin From matt at vazor.com Fri Feb 1 12:02:32 2008 From: matt at vazor.com (Matt Billenstein) Date: Fri, 1 Feb 2008 03:02:32 -0800 Subject: [Catalog-sig] Updating a package that I don't maintain? Message-ID: <20080201110232.GT2478@vazor.com> Hi, I have a bugfix for the Python cjson package: http://pypi.python.org/pypi/python-cjson I submitted a patch to the package author 12/18/2007 -- no response and no newly released package which makes me think he's not actively maintaining it any longer. Is there a process in place if someone other than the current maintainer would like to make an update to a package? thx Matt -- Matt Billenstein matt at vazor.com http://www.vazor.com/ From martin at v.loewis.de Fri Feb 1 20:25:59 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 01 Feb 2008 20:25:59 +0100 Subject: [Catalog-sig] Updating a package that I don't maintain? In-Reply-To: <20080201110232.GT2478@vazor.com> References: <20080201110232.GT2478@vazor.com> Message-ID: <47A37247.8040806@v.loewis.de> > Hi, I have a bugfix for the Python cjson package: > > http://pypi.python.org/pypi/python-cjson > > I submitted a patch to the package author 12/18/2007 -- no response and > no newly released package which makes me think he's not actively > maintaining it any longer. > > Is there a process in place if someone other than the current maintainer > would like to make an update to a package? No. One option would be to fork the project, assuming the license allows for that (i.e. it allows you to modify the source, and to distribute the original code along with your modifications). However, I would recommend to wait. A month is nothing. If there is no response within a year, and after 4 pings or so, you may start to worry. In any case, PyPI has nothing to do with this. It only indexes the packages, but has otherwise no relationship to them, or control over them. Regards, Martin From ianb at colorstudy.com Fri Feb 1 20:31:04 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 01 Feb 2008 13:31:04 -0600 Subject: [Catalog-sig] Updating a package that I don't maintain? In-Reply-To: <20080201110232.GT2478@vazor.com> References: <20080201110232.GT2478@vazor.com> Message-ID: <47A37378.3050802@colorstudy.com> Matt Billenstein wrote: > Hi, I have a bugfix for the Python cjson package: > > http://pypi.python.org/pypi/python-cjson > > I submitted a patch to the package author 12/18/2007 -- no response and > no newly released package which makes me think he's not actively > maintaining it any longer. Keep emailing him. If you are interested in taking over maintenance, ask him about that. Ian From matt at vazor.com Fri Feb 1 22:04:50 2008 From: matt at vazor.com (Matt Billenstein) Date: Fri, 1 Feb 2008 13:04:50 -0800 Subject: [Catalog-sig] Updating a package that I don't maintain? In-Reply-To: <47A37247.8040806@v.loewis.de> References: <20080201110232.GT2478@vazor.com> <47A37247.8040806@v.loewis.de> Message-ID: <20080201210450.GU2478@vazor.com> Thanks guys, it's LGPL, so I'll put up a modified package and patch on my website -- when/if the maintainer gets around to releasing a new package with this fix, I'll take this page down. thx m On Fri, Feb 01, 2008 at 08:25:59PM +0100, "Martin v. L?wis" wrote: > >Hi, I have a bugfix for the Python cjson package: > > > >http://pypi.python.org/pypi/python-cjson > > > >I submitted a patch to the package author 12/18/2007 -- no response and > >no newly released package which makes me think he's not actively > >maintaining it any longer. > > > >Is there a process in place if someone other than the current maintainer > >would like to make an update to a package? > > No. One option would be to fork the project, assuming the license allows > for that (i.e. it allows you to modify the source, and to distribute > the original code along with your modifications). > > However, I would recommend to wait. A month is nothing. If there is no > response within a year, and after 4 pings or so, you may start to worry. > > In any case, PyPI has nothing to do with this. It only indexes the > packages, but has otherwise no relationship to them, or control > over them. > > Regards, > Martin -- Matt Billenstein matt at vazor.com http://www.vazor.com/ From info at thegrantinstitute.com Fri Feb 15 05:08:05 2008 From: info at thegrantinstitute.com (Anthony Jones) Date: 14 Feb 2008 20:08:05 -0800 Subject: [Catalog-sig] Professional Grant Proposal Writing Workshop (May 2008: Salt Lake City, Utah) Message-ID: <20080214200804.E7508BDE518DF817@thegrantinstitute.com> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/catalog-sig/attachments/20080214/eaac2183/attachment.htm From ziade.tarek at gmail.com Thu Feb 21 16:29:40 2008 From: ziade.tarek at gmail.com (=?UTF-8?Q?Tarek_Ziad=C3=A9?=) Date: Thu, 21 Feb 2008 07:29:40 -0800 (PST) Subject: [Catalog-sig] Checking long_description format (reST) before it is sent to PyPI Message-ID: <15613184.post@talk.nabble.com> Hello, while working on disutils register command, and since someone in the plone community suggested it: wouldn't it be interesting to have a warning mechanism on server side when the long_description doesn't compile in reSTructuredText ? (at register time) This would avoid "broken" pages on PyPI where the display is in text where it was intended to be in rendered reST. This could be a simple warning line when the PyPI server meets such a case, and would avoid having to deal with an extra package on client-side (like docutils) ++ Tarek -- View this message in context: http://www.nabble.com/Checking-long_description-format-%28reST%29-before-it-is-sent-to-PyPI-tp15613184p15613184.html Sent from the Python - catalog-sig mailing list archive at Nabble.com. From tim at timhatch.com Fri Feb 22 15:53:21 2008 From: tim at timhatch.com (Tim Hatch) Date: Fri, 22 Feb 2008 08:53:21 -0600 Subject: [Catalog-sig] File size listing in cheeseshop Message-ID: <522EC222-F5A8-4127-AAEF-6A104FEABD6B@timhatch.com> Hi, I'd like to report a minor display nit with the cheeseshop. I hope this is the right place. In the cheeseshop, filesizes listed in MB have the numeric portion shown as an integer (rounded down). It seems to me that it'd be more logical to either round nearest or show a couple of decimal digits. For example, the py23 egg in http://pypi.python.org/pypi/Pygments is listed as "1MB" but is in reality 1,832,489 bytes (1.74MB). Tim From josepharmbruster at gmail.com Fri Feb 22 18:28:49 2008 From: josepharmbruster at gmail.com (Joseph Armbruster) Date: Fri, 22 Feb 2008 12:28:49 -0500 Subject: [Catalog-sig] File size listing in cheeseshop In-Reply-To: <522EC222-F5A8-4127-AAEF-6A104FEABD6B@timhatch.com> References: <522EC222-F5A8-4127-AAEF-6A104FEABD6B@timhatch.com> Message-ID: <47BF0651.4030606@gmail.com> Tim, I do not have a pypi configuration on my server anymore to test this out but I think what you are asking for is a simple change to webui.py. There is a pretty_size function that handles this. See the attached. Joe Tim Hatch wrote: > Hi, > > I'd like to report a minor display nit with the cheeseshop. I hope > this is the right place. In the cheeseshop, filesizes listed in MB > have the numeric portion shown as an integer (rounded down). It > seems to me that it'd be more logical to either round nearest or show > a couple of decimal digits. > > For example, the py23 egg in http://pypi.python.org/pypi/Pygments is > listed as "1MB" but is in reality 1,832,489 bytes (1.74MB). > > Tim > _______________________________________________ > Catalog-SIG mailing list > Catalog-SIG at python.org > http://mail.python.org/mailman/listinfo/catalog-sig > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: filesize.patch Url: http://mail.python.org/pipermail/catalog-sig/attachments/20080222/be5a5148/attachment.txt From benji at benjiyork.com Fri Feb 22 19:09:00 2008 From: benji at benjiyork.com (Benji York) Date: Fri, 22 Feb 2008 13:09:00 -0500 Subject: [Catalog-sig] File size listing in cheeseshop In-Reply-To: <47BF0651.4030606@gmail.com> References: <522EC222-F5A8-4127-AAEF-6A104FEABD6B@timhatch.com> <47BF0651.4030606@gmail.com> Message-ID: <47BF0FBC.2080903@benjiyork.com> Joseph Armbruster wrote: > Index: webui.py > =================================================================== > --- webui.py (revision 524) > +++ webui.py (working copy) > @@ -1572,9 +1572,9 @@ > def pretty_size(self, size): > n = 0 > while size > 1024: > - size /= 1024 > + size /= 1024.0 > n += 1 > - return '%d%sB'%(size, ['', 'K', 'M', 'G'][n]) > + return '%f%sB'%(size, ['', 'K', 'M', 'G'][n]) The fact that this code doesn't work for files larger than 1024 Gig really worries me. ;) <-- wink for the sarcasm-challenged -- Benji York http://benjiyork.com From richardjones at optushome.com.au Mon Feb 25 22:44:39 2008 From: richardjones at optushome.com.au (Richard Jones) Date: Tue, 26 Feb 2008 08:44:39 +1100 Subject: [Catalog-sig] Make setuptools smarter? Message-ID: <200802260844.39835.richardjones@optushome.com.au> PyPI has an xml-rpc interface but it's not being used. What are the chances of getting setuptools to change? Is this something that could be sprinted on at PyCon? Richard From kantrn at rpi.edu Tue Feb 26 01:59:58 2008 From: kantrn at rpi.edu (Noah Kantrowitz) Date: Mon, 25 Feb 2008 19:59:58 -0500 Subject: [Catalog-sig] Make setuptools smarter? In-Reply-To: <200802260844.39835.richardjones@optushome.com.au> References: <200802260844.39835.richardjones@optushome.com.au> Message-ID: <47C3648E.7020002@rpi.edu> Richard Jones wrote: > PyPI has an xml-rpc interface but it's not being used. > > What are the chances of getting setuptools to change? Is this something that > could be sprinted on at PyCon? My understanding was that setuptools was designed to make it possible to use simple static files to make a package repo. This would make it hard to work in something that dynamic. --Noah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://mail.python.org/pipermail/catalog-sig/attachments/20080225/7a71345d/attachment.pgp From pje at telecommunity.com Tue Feb 26 05:08:24 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon, 25 Feb 2008 23:08:24 -0500 Subject: [Catalog-sig] Make setuptools smarter? In-Reply-To: <200802260844.39835.richardjones@optushome.com.au> References: <200802260844.39835.richardjones@optushome.com.au> Message-ID: <20080226040825.F025B3A4088@sparrow.telecommunity.com> At 08:44 AM 2/26/2008 +1100, Richard Jones wrote: >PyPI has an xml-rpc interface but it's not being used. > >What are the chances of getting setuptools to change? See http://www.python.org/dev/peps/pep-0365/ for details on what's supposed to (eventually) use the XML-RPC interface. There are no plans for easy_install to use XML-RPC, however. More precisely, easy_install supports simple, statically-generated package indexes (such as simple directory indexes published by Apache). So, to add XML-RPC support, it would be necessary to have failed XML-RPC calls fall back to the existing static index API -- which adds complexity and server round-trips that wouldn't actually benefit anybody. From richardjones at optushome.com.au Tue Feb 26 06:29:56 2008 From: richardjones at optushome.com.au (Richard Jones) Date: Tue, 26 Feb 2008 16:29:56 +1100 Subject: [Catalog-sig] Make setuptools smarter? Message-ID: <200802260529.m1Q5TuBl009766@mail14.syd.optusnet.com.au> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.python.org/pipermail/catalog-sig/attachments/20080226/384ecd1d/attachment.txt From pje at telecommunity.com Wed Feb 27 21:27:15 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 27 Feb 2008 15:27:15 -0500 Subject: [Catalog-sig] Make setuptools smarter? In-Reply-To: <200802260529.m1Q5TuBl009766@mail14.syd.optusnet.com.au> References: <200802260529.m1Q5TuBl009766@mail14.syd.optusnet.com.au> Message-ID: <20080227202701.8F9BE3A4088@sparrow.telecommunity.com> At 04:29 PM 2/26/2008 +1100, Richard Jones wrote: >Phillip J. Eby wrote: > > At 08:44 AM 2/26/2008 +1100, Richard Jones wrote: > > >PyPI has an xml-rpc interface but it's not being used. > > > > > >What are the chances of getting setuptools to change? > > > > See http://www.python.org/dev/peps/pep-0365/ for details on what's > > supposed to (eventually) use the XML-RPC interface. > >I wasn't aware of that PEP, thanks! Is there any more detail on what >XML-RPC features you'd need to support it? AFAIK, it should be possible to do with the existing API, since it will only be supporting downloads for files found directly on PyPI. (i.e., no third-party distribution sites). The MD5's are included in that API already. To find the package, I was thinking I would use package_releases(), and if nothing is found, falling back to search() using the longest alphanumeric substring of the canonicalized package name, then filtering the results that come back. Then, it'd be on to picking a compatible bdist_egg out of release_urls(). One minor possible hurdle is that package_releases() doesn't list *all* available versions, only the "unhidden" ones. It might be nice to have a separate API to request *all* versions. OTOH, I have to say that the availability of the new "simple" API makes it a lot more tempting to just use that. Because there, I can make just *one* server round trip to get all the data I need, assuming that the user has properly spelled and capitalized the package name. Whereas, with the XML-RPC API, it requires a minimum of two calls. (And of course, the "simple" API can be statically mirrored, while XML-RPC cannot.) From richardjones at optushome.com.au Wed Feb 27 21:54:28 2008 From: richardjones at optushome.com.au (Richard Jones) Date: Thu, 28 Feb 2008 07:54:28 +1100 Subject: [Catalog-sig] Make setuptools smarter? In-Reply-To: <20080227202701.8F9BE3A4088@sparrow.telecommunity.com> References: <200802260529.m1Q5TuBl009766@mail14.syd.optusnet.com.au> <20080227202701.8F9BE3A4088@sparrow.telecommunity.com> Message-ID: <200802280754.29101.richardjones@optushome.com.au> On Thu, 28 Feb 2008, Phillip J. Eby wrote: > One minor possible hurdle is that package_releases() doesn't list > *all* available versions, only the "unhidden" ones. It might be nice > to have a separate API to request *all* versions. Done. package_relases now takes (package_name, show_hidden=False) - setting show_hidden to True will make it list all versions, hidden or not. > OTOH, I have to say that the availability of the new "simple" API > makes it a lot more tempting to just use that. Because there, I can > make just *one* server round trip to get all the data I need, > assuming that the user has properly spelled and capitalized the > package name. Whereas, with the XML-RPC API, it requires a minimum > of two calls. Unless we write a new call ... what_setuptools_needs(package_name) which does a search on the name, then case-insensitive if that fails and returns the egg URLs. > (And of course, the "simple" API can be statically > mirrored, while XML-RPC cannot.) Yep. Richard From pje at telecommunity.com Wed Feb 27 22:31:18 2008 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed, 27 Feb 2008 16:31:18 -0500 Subject: [Catalog-sig] Make setuptools smarter? In-Reply-To: <200802280754.29101.richardjones@optushome.com.au> References: <200802260529.m1Q5TuBl009766@mail14.syd.optusnet.com.au> <20080227202701.8F9BE3A4088@sparrow.telecommunity.com> <200802280754.29101.richardjones@optushome.com.au> Message-ID: <20080227213128.C77873A4088@sparrow.telecommunity.com> At 07:54 AM 2/28/2008 +1100, Richard Jones wrote: >On Thu, 28 Feb 2008, Phillip J. Eby wrote: > > One minor possible hurdle is that package_releases() doesn't list > > *all* available versions, only the "unhidden" ones. It might be nice > > to have a separate API to request *all* versions. > >Done. package_relases now takes (package_name, show_hidden=False) - setting >show_hidden to True will make it list all versions, hidden or not. > > > > OTOH, I have to say that the availability of the new "simple" API > > makes it a lot more tempting to just use that. Because there, I can > > make just *one* server round trip to get all the data I need, > > assuming that the user has properly spelled and capitalized the > > package name. Whereas, with the XML-RPC API, it requires a minimum > > of two calls. > >Unless we write a new call ... what_setuptools_needs(package_name) which does >a search on the name, then case-insensitive if that fails and returns the egg >URLs. Or you could just make it so that release_urls() doesn't need a second argument, and if omitted, returns a dictionary of all versions' download information. That would make it single-roundtrip in the case where somebody spells the name correctly and case-matched. By the way, speaking of name matching, was there ever a decision reached about name canonicalization for PyPI? (i.e., disallowing registration of packages that have identical names except for case or punctuation?) > > (And of course, the "simple" API can be statically > > mirrored, while XML-RPC cannot.) > >Yep. Right - so I don't really see what the benefit of using the XML-RPC here is. If the people who are maintaining PyPI really want that, I guess we could do it. But ISTM that since the "simple" API is already officially supported and widely used/tested, scaling up the load on XML-RPC might actually be a bad idea, from a "keeping PyPI running" point of view. And of course, it's another API. Besides, aren't REST APIs all the rage these days, anyway? XML-RPC is like, soooo 2003. ;-)