<div><span style="color: rgb(160, 160, 168); ">On Friday, March 1, 2013 at 6:04 AM, M.-A. Lemburg wrote:</span></div>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div>On 01.03.2013 11:19, holger krekel wrote:</div><blockquote type="cite"><div><div>Hi Richard, all,</div><div><br></div><div>somewhere deep in the threads i mentioned i wrote a little "cleanpypi.py"</div><div>script which takes a project name as an argument and then goes to </div><div><a href="http://pypi.python.org">pypi.python.org</a> and removes all homepage/download metadata entries for </div><div>this project.  This sanitizes/speeds up installation because</div><div>pip/easy_install don't need to crawl them anymore.  I just did this for</div><div>three of my projects, (pytest, tox and py) and it seems to work fine.</div></div></blockquote><div><br></div><div>Does it also cleanup the links that PyPI adds to the /simple/ by</div><div>parsing the project description for links ?</div><div><br></div><div>I think those are far nastier than the homepage and download links,</div><div>which can be put to some good use to limit the external lookups</div><div>(see <a href="http://wiki.python.org/moin/PyPI/DownloadMetaDataProposal">http://wiki.python.org/moin/PyPI/DownloadMetaDataProposal</a>)</div><div><br></div><div>See e.g. <a href="https://pypi.python.org/simple/zc.buildout/">https://pypi.python.org/simple/zc.buildout/</a></div><div>for a good example of the mess this generates... even mailto links</div><div>get listed and "file:///" links open up the installers for all</div><div>kinds of nasty things (unless they explicitly protect against</div><div>following these).</div></div></div></span></blockquote><div>pip at least, and I assume the other tools don't spider those links, but</div><div>they do consider them for download (e.g. if the link looks installable</div><div>it will be a candidate for installing, but  it won't fetch it, and look for </div><div>more links like it will donwnload_url/home_page).</div><div><br></div><div>I believe that's the way it's structured atm.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><blockquote type="cite"><div><div>Now before i release this as a tool, i wonder: Is it a good idea to remove</div><div>download/homepage entries?  Is there any current machine use (other than</div><div>the dreaded crawling) for the homepage/download_url per-release metadata </div><div>fields?</div><div><br></div><div>For humans the homepage link is nicely discoverable if the long-description</div><div>doesn't mention it prominently.  But i think there also is a "project url" </div><div>or "bugtrack url" for a project so maybe those could be used to reference </div><div>these important pages?  (i am a bit confused on the exact meaning of those</div><div>urls, btw).</div><div><br></div><div>Should we maybe stop advertising "homepage" and "download_url"</div><div>and instead see to extend project-url/bugtrackurl to be used</div><div>and shown nicely? The latter are independent of releases which i think</div><div>makes sense - what use are old probably unreachable/borked homepages</div><div>anyway.  And it's also not too bad having to go once to <a href="http://pypi.python.org">pypi.python.org</a></div><div>to set it, usually it seldomly changes.</div></div></blockquote><div><br></div><div>I think it would be better to differentiate between showing the</div><div>fields on the project pages, where they provide useful resources</div><div>for people, and their use on the /simple/ index pages which are</div><div>meant for programs to parse.</div><div><br></div><div>IMO, the homepage and download links on the project pages are</div><div>indeed very useful for people. On the /simple/ index a homepage</div><div>link is probably not all that useful (provided a download link</div><div>is set). The download links serve the purpose of directing</div><div>tools to the right location, so those do belong on the /simple/</div><div>index listings. I'd completely remove the links parsed from</div><div>the descriptions, since those don't really provide a good</div><div>basis for crawling (the description is meant for humans to</div><div>parse, not programs).</div><div><br></div><div>-- </div><div>Marc-Andre Lemburg</div><div><a href="http://eGenix.com">eGenix.com</a></div><div><br></div><div>Professional Python Services directly from the Source  (#1, Mar 01 2013)</div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><div><div>Python Projects, Consulting and Support ...   <a href="http://www.egenix.com">http://www.egenix.com</a>/</div><div>mxODBC.Zope/Plone.Database.Adapter ...       <a href="http://zope.egenix.com">http://zope.egenix.com</a>/</div><div>mxODBC, mxDateTime, mxTextTools ...        <a href="http://python.egenix.com">http://python.egenix.com</a>/</div></div></blockquote></blockquote></blockquote><div>________________________________________________________________________</div><div><br></div><div>::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::</div><div><br></div><div>   <a href="http://eGenix.com">eGenix.com</a> Software, Skills and Services GmbH  Pastor-Loeh-Str.48</div><div>    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg</div><div>           Registered at Amtsgericht Duesseldorf: HRB 46611</div><div>               <a href="http://www.egenix.com/company/contact/">http://www.egenix.com/company/contact/</a></div><div>_______________________________________________</div><div>Catalog-SIG mailing list</div><div><a href="mailto:Catalog-SIG@python.org">Catalog-SIG@python.org</a></div><div><a href="http://mail.python.org/mailman/listinfo/catalog-sig">http://mail.python.org/mailman/listinfo/catalog-sig</a></div></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>