<div class="gmail_quote"><div class="gmail_quote">On Thu, Jun 17, 2010 at 13:40, M.-A. Lemburg <span dir="ltr"><<a href="mailto:mal@egenix.com" target="_blank">mal@egenix.com</a>></span> wrote:<div class="im"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div>Patrick Gerken wrote:</div></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
<br>
> As a plone user who uses zc.buildout I very much prefer reliable downloads.<br>
> Its not fun<br>
> to search for the reason a supposedly repeatable buildout suddenly fails<br>
> because<br>
> a company decided to rename itself.<br>
<br>
</div>It is well possible to delete package listings on PyPI. Wouldn't<br>
you rather be informed about this by way of an error report in<br>
zc.buildout than by finding that the package name has changed<br>
a few years later ?<br></blockquote></div><div><br>I would prefer to have my buildout to be working. I do not always need the newest<br>versions, and we have cases where customers are working with a specific<br>version of plone where some additional packages made backward incompatible<br>
changes that prohibit us from using them for these clients.<br>So yes, I prefer working on a potentially outdated version. <br>During development we check regulary for new versions. We have tools for that. <br><div class="im">
<br><br>
> How about only listing packages with provided source code on the simple<br>
> interface?<br>
> afaik buildout always uses that, so a package python-openid is visible in<br>
> the<br>
> end-user view, but not installable via buildout. That way nobody would ever<br>
> have had<br>
> created a dependency on it in the first place.<br>
<br>
</div></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If such external links are a problem for zc.buildout, why don't<br>
you add an option to zc.buildout that prevents using such<br>
packages ?<br></blockquote></div><div><br>Because I consider pypi the root cause of the problem. Not the tools.<br>pip also allows repeatable package sets be defining specific version<br>requirements. Should this then be patched too?<br>
<br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is well possible by checking the /simple index entry<br>
for links to package download files:<br>
<br>
<a href="http://pypi.python.org/simple/python-openid/" target="_blank">http://pypi.python.org/simple/python-openid/</a><br>
<br>
vs.<br>
<br>
<a href="http://pypi.python.org/simple/zc.buildout/" target="_blank">http://pypi.python.org/simple/zc.buildout/</a><br>
<br>
BTW: what are all those bug links doing on the zc.buildout index page ?<br>
They look a lot like a good possibility for injecting trojans.<br></blockquote></div><div><br>I don't know. <br><br>What about the suggestion to show all packages on pypi but not all on the simple view?<br>I can imagine that having your packages advertised on pypi generates reasonable revenue<br>
and I am absolutely not against that. <br>But I am against a pypi index that can not promise to keep its advertised packages available.<br>the simple index view is meant for machines, and I'd perfectly happy if constraints<br>
suggested by Andreas would only be applied to that simple index.<br></div></div><br>Best regards,<br><font color="#888888"><br> Patrick<br>
</font></div><br>