While I investigated SLAPOS-EGG-TEST-PY3 failure, I realized that our network cache integration did not fit with find-links. On the original buildout, find-links are used only once and it makes sense because buildout gets the latest contents of the URLs of find-links. But we uses network cache, when find-links are used only once with a requirement, most of the time, buildout gets a cached page that was fetched some time ago, so we did not have a chance to use our find-links URLs(http://www.nexedi.org/static/packages/source/ etc) to look for our custom packages. Because buildout collects all possible distributions' links even unrelated things from a fetched index(buildout can find distributions of zc.buildout when it fetched an index page of setuptools for example), we did not notice this problem.

In fact, for zc.buildout=2.5.2+slapos014, shacache did not have a cache of http://www.nexedi.org/static/packages/source/slapos.buildout/ and buildout did not use this URL to find a distrubution of that because that URL of find-links were already used once in prescan method when buildout looked for a distribution of setuptools=40.4.3, then buildout received a cached page of that URL made for setuptools=40.4.3 several month ago that did not contain a link for zc.buildout=2.5.2+slapos014.

My change is:

• Remove prescan and stop deleting find-links, make find-links usable any number of times.
• In obtain method, first try to find a required package from the standard index, if it did not find any matched packages, use find-links one by one until a requirement is met.

Then, buildout will use find-links every time when it looks for our custom package that is not found in the standard index and each our custom package will hold a cached index page in shacache which we don't have now.

I will accept this MR soon. I already succeeded to build a ERP5 SR and a SR for SLAPOS-EGG-TEST-PY3 with my fixed zc.buildout.