@hvelarde Thanks for the tip on containers but I think you missed the point. What you have doesn't work for plone versions 4.0.x, 4.1.x, 4.2.x. It currently only works for 4.3 and 5.0 but also might break in the future since bootstrap.py has proved unreliable. This is an attempt to use a more robust bootstrapping process that extracts the versions needed for zc.buildout and setuptools and installs them via virtualenv.
@jensens I was just thinking this could be improved by doing installing zc.buildout via pip first. using that to extract the right versions from the .cfg and then getting pip downgrade zc.buildout and setuptools. Then bootstrap.py could be remove completely.
in general, most of the time I skip testing for Plone 4.0 as is really hard to keep compatibility with it unless your add-on is really simple.
I had problems in the past with bootstrap.py but keeping it updated in the latest version solved them all. I tried also different approaches but they seemed less reliable overall and I don't want to deal with different ways of doing things.
no, the travis.cfg configuration was a hack @datakurre developed before the Travis CI container-based infrastructure was available. it's totally unnecessary right now and adds overhead to the simple process of having just one buildout configuration for development and CI.
it must be removed from bobtemplates.plone as is not a best practice at all.
@hvelarde I've no idea what you think I noticed but perhaps you didn't read the code before commenting? This solution stands as a way to get a working buildout without needing to update bootstrap.py. It is bootstrap.py problem free, something I can't be bothered with.
I don't care that you don't care how I initialise a buildout. I do care that "how to best initialize a buildout" is the entire point of this thread and you hijacked it. If you care so much about an optimisation like caching then start your own thread on it. It's irrelevant to this discussion.