<div dir="ltr"><br><br><div class="gmail_quote">2008/8/12 Phillip J. Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 02:13 PM 8/12/2008 +0200, Tarek Ziade wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2008/8/12 Jim Fulton <<mailto:<a href="mailto:jim@zope.com" target="_blank">jim@zope.com</a>><a href="mailto:jim@zope.com" target="_blank">jim@zope.com</a>><div class="Ih2E3d"><br>
<br>
On Aug 12, 2008, at 4:41 AM, Tarek Ziade wrote:<br>
...<br>
<br>
Since mirrors for PyPI and alternative egg servers are being , what about making the "index" variable in<br>
zc.buildout accept multiple values, like what find-links does ?<br>
<br>
<br>
<br>
Buildout uses and tries hard to be compatible with setuptools. In particular, it relies on the setuptools.package_index.PackageIndex class, which only allows a single index to be provided.<br>
<br>
<br>
Yes, I was thinking of handling several PackageIndex instances on zc.buildout side as a first thaught.<br>
</div></blockquote>
<br>
What you really want/need is to make the PackageIndex support retrieval from multiple index urls; the PackageIndex itself aggregates available packages from sources such as the local file system, -f urls, and an underlying package index. So having multiple aggregators would duplicate processing, and deprive you of a global ordering of package precedences.<br>
<br>
</blockquote></div><br>Is this a feature you would like to see in setuptools ? If so I can write a patch,<br><br>Besides this feature, there's one feature we started to add on zc.buildout but could be put in setuptools's PackageIndex as well I believe :<br>
<br>Adding timeouts for url openings, to speed up the processing. For instance, when several urls are visited for<br>a given package, and when a server pointed by one of the url is down, it can last forever. <br><br>
urlib2.urlopen does not have a timeout option yet, even if it has been discussed for Python 2.6 inclusion, 2 years ago [1]<br>So we used <em>socket</em>.<em>setdefaulttimeout</em>() , which looks safe to change in this use case.<br>
<br>At zc.buildout level, we could wait for up to 5 minutes to finish a buildout upgrade, <br>and setting the timeout to a few seconds solved the problem efficiently.<br><br>In a shape of a decorator, that could be :<br><br>
# five seconds<br>TIMEOUT = 5 <br><br>def timedout(func):<br> def _timedout(*args, **kw):<br> old =socket.getdefaulttimeout()<br> socket.setdefaulttimeout(TIMEOUT)<br> try:<br> return func(*args, **kw)<br>
finally:<br> socket.setdefaulttimeout(old) <br> return _timedout<br><br><br>Tarek<br><br>[1] <a href="http://mail.python.org/pipermail/python-dev/2006-July/066965.html">http://mail.python.org/pipermail/python-dev/2006-July/066965.html</a><br clear="all">
<br>-- <br>Tarek Ziadé - Directeur Technique<br>INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632<br>Bureaux de la Colline - 1 rue Royale - Bâtiment D - 9ème étage<br>92210 Saint Cloud - France<br>Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04<br>
<a href="http://www.ingeniweb.com">http://www.ingeniweb.com</a> - une société du groupe Alter Way<br>
</div>