I actually think that Heroku's API of three simple bash entry points is a great solution to this problem. Today, there is nothing to stop you from writing a buildpack in Go. Aligning with that, I don't think there there should be any requirement to use shared utility code either; it should simply be available if you want to.
The key here is rather than mandating a language or infrastructure APIs (e.g. caching, configuration) let the most compelling choices organically grow. If Go really is a better language for writing buildpacks then it will win. If it turns out that Ruby (or Node, or Python) is better, than those will win. We're still way too early to pick a winner.
I'm not sure what you mean by "this problem". I agree that the three Heroku entry points are a good external interface to buildpacks, but they don't solve the problem of sharing infrastructure between buildpacks.I actually think that Heroku's API of three simple bash entry points is a great solution to this problem. Today, there is nothing to stop you from writing a buildpack in Go. Aligning with that, I don't think there there should be any requirement to use shared utility code either; it should simply be available if you want to.
Thanks Ben, Daniel, and Glyn for sharing your views on this and for your efforts to provide reuseable code other buildpacks to reuse.
It's a bit harder for cf users and potential contributors to keep up with a wide variety of languages in the cf ecosystem (go, ruby, python, bash) with each their own set of tools (dependency mgt, test/mock frameworks...), but I guess that's also what makes a rich, open and diverse community.
I'm wondering whether some generic features that were recently brought by buildpacks could be moved into the cf bosh release, or in common development tools, so that they benefit to all newly created buildpacks, e.g.
- could the buildpack cache feature be a standalone HTTP caching proxy (along with the debugging traces showing the buildpack cache content when debugging is enabled)
- some of the diagnostics developments in the java buildpack be moved to the dea (e.g. displaying last git commits for a custom git repo when debugging is enabled)
- enabling buildpack debugging traces could be standardized across buildpacks and potentially support added to cf cli and dea ?- could the integration testing contributed by java buildpack  be used as generic testsuite for buildpacks, verifying the buildpack properly startup an application, and possibly inject properly credentials so that apps can use them ?