[Catalog-sig] Proposal: Move PyPI static data to the cloud for better availability
Ronald Oussoren
ronaldoussoren at mac.com
Tue Jun 15 19:15:00 CEST 2010
On 15 Jun, 2010, at 19:02, Tarek Ziadé wrote:
> On Tue, Jun 15, 2010 at 6:02 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Alexis Métaireau wrote:
>>> Hello,
>>>
>>> Firstly, as Tarek said in another thread, I'm afraid this kill the PEP381
>>> about making a mirroring infrastructure.
>>> Having a infrastructure hosted on a cloud platform may be confortable, and
>>> probably needed to have a 24/7 running system, but
>>> we need to take care of letting possible the creation of new public mirrors,
>>> outside from the Amazon (or whatever) cloud infrastructure.
>>
>> The proposal doesn't prevent that. However, please note that
>> setting up public mirrors not under PSF control has its own
>> set of (legal) problems, which the PSF hosted cloud setup avoids.
>
> Mirrors already exists out there, so unless you ban them (which would
> be a really bad idea)
> setting up a cloud will not fix any legal issue if you think there's a
> legal issue.
>
> In any case, you can't prevent people from creating mirrors even if you
> would say its illegal. Moreover, having mirrors provided by the community
> is way better than relying on one single entity (the PSF) for this.
> (if we think "decentralized")
Why is having community mirrors better than one managed by the PSF?
Even with community mirrors the contents of PyPI are still controlled by the PSF, because they control the master server, there is not much decentralization in that respect.
AFAIK the goal of this exercise is to improve the uptime of the PyPI download service as used by existing installation, MAL's proposal seems like an easy way to accomplish that with minimal effort.
Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20100615/a91f16f1/attachment-0001.bin>
More information about the Catalog-SIG
mailing list