[jacques_chester]

> But nothing about this changes my opinion that this is an opinionated builder that when you get to the point that you need to do something a bit funky or weird in your application or build process you will end up needing to ditch it and build a Dockerfile anyways.

"Sometimes there's a power outage, so I am forced to use candles anyhow. Therefore I should only use candles for lighting."

[nerdjon]

I am sorry but that that analogy does not work.

Using candles does not add any complexity to your lighting situation.

But if half of my applications can use docker and half can (for now) use BuildPacks that adds needless complications to my build and dev environment for minimal (if any) benefit.

[jacques_chester]

I don't see it as a net increase in complexity. Buildpacks pay their freight and then some.

[nerdjon]

It is yet another thing to manage and train people on as part of a CI/CD pipeline and development workflow.

It would add the complication of, if I am looking at a given service needing to determine if it was built with a DockerFile or Buildpack.

And then when that application outgrows Buildpack it will ultimately be easier (due to knowledge that everyone already has working with Docker) to do whatever the special thing that application, tool, whatever needs in a DockerFile than try to understand BuildPack.

Opiniated tools are great, but time and time again when what we need deviates slightly from the "norm" they become overly complicated to manage and going with the standard option like a DockerFile would have been better in the first place.

[jacques_chester]

I believe I understand your argument, but my experiences lead me to allocate the balance of risks differently. I think buildpacks are net win in spite of the potential problems you are pointing out.

Agree to disagree?