Should we propose a new repo for buildpacks?

[lance]

Currently, we are using a couple of buildpacks from Boson to augment the Paketo buildpacks for our builtin. The source for these is here https://github.com/boson-project/packs and the images are distributed here https://github.com/orgs/boson-project/packages.

These are used for Go and TypeScript functions. For Go, it's where the function scaffolding code is injected into the image. For TypeScript it simply runs the transpilation since the Paketo buildpacks don't seem to provide a hook for a build step.

Any opinions on whether these should actually be published by the knative-sandbox community?

[lkingland]

Since these are part of the builtin functionality of func, it seems to make sense to have them in the same org as func itself; if that is possible.

[lance]

We are now down to only a single buildpack, fwiw: boson-project/packs#2 (assuming someone approves this pr!)

[evankanderson]

Is there any particular need for the buildpacks to be owned / maintained by the Knative community?

IMO, one of the larger goals of the func effort should be to figure out what parts of the experience are a common core, and which parts are pluggable. For the pluggable components, I'd be happy to see things mostly organized out-of-core. (Google did this for the GCP broker, but a lot of the eventing components ended up being co-evolved along with their interfaces in knative/eventing-contrib for a while before being broken out.)

Another good example of this is the TriggerMesh event sources: https://github.com/triggermesh/triggermesh and search for "TriggerMesh" on https://knative.dev/docs/eventing/sources

Personally, I'd be happy to reference the boson project and direct users there for the buildpacks to enable function support.

[lance]

Thanks for this insight @evankanderson.

IMO, one of the larger goals of the func effort should be to figure out what parts of the experience are a common core, and which parts are pluggable.

I definitely agree with this. I guess in this case, it's not entirely black and white since the buildpack reference is compiled into the func binary. As a whole, language packs are "pluggable". But for the built in Go templates, there is this one little buildpack that is required.

[evankanderson]

Larger question: should we have built-in references in the go binary at all? My experience in other projects that these built-in dependencies produce more pain than benefit (who gets to be built-in, the built-in components inevitably get extra support/attention, etc).

[lance]

I think there is something to be said for having a CLI that has everything you need out of the box and which does not require additional steps such as downloading a language pack to get started. So I do think it's important to have at least a couple of built in templates (I could be persuaded to remove some of them, probably). Consider that even if we do remove these templates, and make them externally installable langauge packs, the language packs themselves will need to live somewhere. And presumably if that somewhere is knative-sandbox they'll get extra attention. And if it's not knative-sandbox then where? Perhaps boson-project is the right place. But even there, if they are the default language packs that we instruct users to install in order to get started and actually do anything, they'll still get more love and attention.

[evankanderson]

I'm happy to pay tribute to boson-project for the buildpacks, or possibly other upstream communities if we can -- I think the Spring team is at least somewhat interested in owning the Spring Boot buildpack long-term.

[lance]

Related: #1451

[lkingland]

The present architecture injects scaffolding code (the Functions middleware) into the process at time of func build, obviating the need for the Functions-specific buildpacks. They are being steadily phased out as more runtimes are updated.