On 9/27/11 9:07 AM, Tarek Ziadé wrote:
On Tue, Sep 27, 2011 at 3:00 PM, Wichert Akkerman
wrote: On 09/27/2011 02:51 PM, Tarek Ziadé wrote:
On Tue, Sep 27, 2011 at 2:39 PM, Wichert Akkerman
wrote: .. I understand where you're coming from but, .. I think it's saner to rely on proven technology than to invent our own protocol. NIH?
This also feels like a problem that has already been solved in various ways by Debian, RedHat, CPAN and others.
Yes, and we've found a way similar to CPAN, with some Python specifics (PyPI download statistics mainly)
Oh my, we're cycling again.
Nothing personal to you or Jim, but I have a sudden fatigue on packaging because it seems like people are ignoring what's being done to complain afterwards about us suffering of some kind of NIH :)
It's just that my perspective is that of a simple user. And from my perspective nothing has changed in the last couple of years. Pypi still goes down occasionally, and when that happens many things start breaking. It may very well be that there are things planned or in progress, but until they are both usable and used by standard tools, which for me means buildout and setuptools, they are invisible.
Fair enough,
Pip has now the mirroring protocol implemented. I think they want to make it a default option for the next major Pip release. IOW, you should not suffer for downtimes using pip.
We'd need to add the same feature in easy_installand zc.buildout. But since Pip did it, I think it's possible.
We have 5 mirrors run by the community (http://pypi.python.org/mirrors) and I suspect porting pip's feature to zc.buildout and easy_install would take less time than creating a <Name your cloud service> app.
I'm not sure I fully understand why each-tool needs updating (vs. something that would provide HA but be invisible to the tools), but I suspect a lot of this is "legacy" related (i.e. PyPI was not originally designed to handle HA) and adding support to each tool, though potentially tedious-sounding (if not actually tedious) may be reasonable. Alex
Cheers Tarek
Wichert.
-- Alex Clark · http://aclark.net