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 + <some code> 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 <pje at telecommunity.com> 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. ;-)