Glossary of Buildpacks (Align on useful buildpacks terminology)

[fg-j]

In the Working Group meeting on 3/16/21, we discussed that there are many buildpacks concepts that don't have intuitive nouns to name them that we all agree upon. Some examples include:

1. Layers that a buildpack adds to a launch image to include an exec.d script that the lifecycle will run at container launch time
2. A more descriptive name for a "metabuildpack"
3. Buildpacks whose sole job is to install a dependency and put it on the $PATH

In this discussion, let's collect more of these "concepts that need nouns" and propose words for them. Some of these might end up in Paketo docs, some might end up as changes to the upstream Cloud Native Buildpacks specification.

If you're proposing a concept + name, it'd be helpful if you link to concrete examples of said concept. These could be lines of code, whole buildpacks, frequently-used patterns, etc.

[ForestEckhardt]

Another concept to consider is a buildpack that runs some build process does not produce consumable layers, something like go-mod-vendor, which vendors your app but only produces a cache layer which it uses on rebuilds.

[arjun024]

"Launch process buildpack" Aka "Start command buildpack" e.g. https://github.com/paketo-buildpacks/unicorn

[fg-j]

I think I like "launch process" because it's reflected in the CNB spec terminology for what happens at launch time: "...buildpack-provided process type is chosen as the start command"

Meaning that buildpacks provide launch processes and the lifecycle sets a start command

[fg-j]

We've got a bunch of buildpacks whose only job is to install a distribution or tool (as mentioned in @sophiewigmore 's blog post)

These include:

• go-dist
• bundler
• yarn

I propose we call these "Dependency Installation Buildpacks"

This (hopefully) distinguishes them from buildpacks that install or vendor your app's dependencies, like

• bundle install or
• go mod vendor

which we might call "Vendoring Buildpacks"

[ryanmoran]

I think "Vendoring Buildpacks" may represent a subset of a larger group you might call "Build Process Buildpacks". This larger group also includes buildpacks that compile your code like go-build or rails-assets.

[arjun024]

(This has a noun but useful to be documented at a central place)

• Project Path - as used in https://github.com/paketo-buildpacks/dotnet-publish/blob/v0.1.4/README.md#buildpackyml-configurations

[dmikusa]

I think it would help to have a term for buildpacks that do not care what stack they run on. Examples would be buildpacks that just run a tool that is on the PATH (php-composer) or most buildpacks that just end up setting a start command (i.e. launch process buildpacks -> #8 (comment)).

Possible names: stack agnostic buildpack or noarch buildpack

[dmikusa]

I don't think we have a term to call environment variables set specifically to configure a buildpack, like BP_TOMCAT_CONTEXT_PATH or BP_JVM_VERSION or BPL_JVM_HEAD_ROOM.

Possible names: buildpack configuration variables or buildpack setting variables

[fg-j]

On the Paketo site, we refer to the metabuildpacks as

• metabuildpacks
• language family buildpacks
• composite buildpacks

[fg-j]

I think "composite buildpacks" is more clear than "metabuildpacks" .

And, I suppose, the Paketo language family buildpacks are a type of composite buildpack.