[Catalog-sig] PyPI down again...
mal at egenix.com
Mon Jun 14 16:12:49 CEST 2010
When designing such interfaces, please consider that the PyPI information
is mostly static. If there's information missing, it should be easy to add
it to e.g. a new info file placed into the package's "simple" directory
that package tools could pick up in REST style.
Static directories just scale a lot better than any kind of (true) RPC
interface and offloading some work to the client is certainly
a good strategy as well.
Professional Python Services directly from the Source (#1, Jun 14 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2010-07-19: EuroPython 2010, Birmingham, UK 34 days to go
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
Alexis Métaireau wrote:
> Hi all,
> Distutils2 will bring two APIs to request PyPI, via the "simple" API and via
> the XML-RPC one.
> The fact is that the Simple API (it's just HTML pages, in a REST style as
> pointed out by Mark)
> does not provides all information we need, especially about distribution
> dependencies or if we want to query some others things contained in the
> I'm working on two simple APIs for that, and I'll probably make a wrapper
> around both, wich could choose the right one to use, depending on the needs
> (eg. don't always rely on RPC or on "REST").
> As we are talking about refactoring PyPI, it will probably be nice to have a
> real REST API, that talks JSON or XML, replacing the HTML pages actually
> served on http://pypi.python.org/simple/ :)
> On Mon, Jun 14, 2010 at 1:50 PM, Mark Ramm <mark at geek.net> wrote:
>>> If, in the future, package tools start to rely on RPC for
>>> fetching data, the situation will shift towards needing full
>>> functional mirrors again.
>> Ideally we move some of this to be accessible via a more REST style
>> interface where http GET requests (which would be by far the most
>> common case) are still cacheable via all the standard mechanisms.
>> I'm not a REST evangelist in most cases, but when scale and
>> availability really do matter, REST buys you quite a bit by allowing
>> you to scale and cache in all the ways that the web does.
>> --Mark Ramm
>> Catalog-SIG mailing list
>> Catalog-SIG at python.org
More information about the Catalog-SIG