
Paketo: Modular Buildpacks in Go - kvedurmu
https://paketo.io/
======
antoncohen
Some feedback on the page. I think I'm squarely in the target audience. I'm
familiar with Heroku Buildpacks. I wrote my own tool to generically build
projects by detecting languages, build tools, etc. I based the detection of
Heroku Buildpacks. And I packaged the tool into builder images.

But reading this page, I can't tell what Paketo Buildpacks do, when I'd use
them, or how I'd use them. Usage examples would probably help. Some clear call
out of "You want to do X, we solve that".

For examples of why this page is hard to understand, see these sections:

\- _What are Buildpacks?_ \- Basically says "CNCF Buildpacks are an evolution
of buildpacks"

\- _What are Paketo Buildpacks?_ \- Basically says "they use Cloud Native
Buildpacks"

\- _Why Paketo Buildpacks?_ \- Basically says "unlike other buildpacks, we are
better buildpacks"

Even knowing what buildpacks are in general, and building container build
automating for a living, I can't tell if I have a use for Paketo Buildpacks.

~~~
hardwaresofton
+1 I am very much _not_ the target audience (I don't really use build packs
much), but I'm interested in the space (I am toying with the idea of running a
PaaS) and it is very unclear to me why I would use this project instead of
pack[0].

Currently I'm just defaulting to thinking that this is Cloud Foundry's attempt
to enter the buildpack space, since standardization of the buildpack ecosystem
(and adherence to set standards) lowers the bar of entry for them.

[0]: [https://buildpacks.io/docs/install-
pack/](https://buildpacks.io/docs/install-pack/)

~~~
dwillist
Thanks for the feedback about clarity. Paketo Buildpacks are supposed to be
used with pack. Basic equation is (Pack) + (Cloud Native Buildpacks) = (OCI
image). Packeto Buildpacks are an option for the Cloud Native Buildpacks
piece.

~~~
hardwaresofton
No problem, apologies for my misunderstanding of where Cloud Foundry was in
the space, had no idea it was involved so much in the initial buildpacks
breakout & standardization.

I understand very well where packeto fits in the buildpack space now, and how
it integrates with `pack` itself.

------
arendtio
As someone who is not familiar with Buildpacks, I find that page particularly
hard to understand. I see promising headlines like "What are Paketo
Buildpacks?" just to be greeted by more unknown terms (e.g. 'Buildpacks').

You might want to explain what you are doing to an outsider and let him write
the intro ;-)

~~~
kvedurmu
Hey, I'm a PM contributing to the Paketo project. This is great feedback and
something that we'll definitely work on improving on the website. I totally
get that it's difficult to understand this content if you're not too familiar
with Cloud Native Buildpacks.

In the meantime, are there any questions about Buildpacks and/or the Paketo
project that we could help clarify? If you're interested in learning more
about the buildpack architecture I'd suggest watching this Cloud Native
Buildpacks intro talk that explains things pretty well -
[https://www.youtube.com/watch?v=SK6e_ZatOaw](https://www.youtube.com/watch?v=SK6e_ZatOaw)

------
jbeda
If y'all want more discussion on this, I tweeted about Paketo and why I find
it interesting:
[https://twitter.com/jbeda/status/1252974134532780034](https://twitter.com/jbeda/status/1252974134532780034)

------
pachico
Ok, the headline got my attention. After looking browsing the site I just
hardly know what it is about. The only example I find is published in Github
under a personal account and it only covers a hello world in node.js. I'm sure
this is a killer app but, dammit, I wish they spent some more time in docs.
I'll check it out now and then.

------
jacques_chester
One thing that may not be immediately obvious: Paketo is backed by release
engineering code, infrastructure[0] and know-how accumulated over 6 or so
years of sustained engineering. I was lucky to work on some of it in 2014 and
2016, a year or two before the technologies directly feeding into Paketo were
first developed.

The engineering and infrastructure costs millions of dollars per year. And you
can get the benefit for free.

[0] [https://buildpacks.ci.cf-app.com/](https://buildpacks.ci.cf-app.com/)

~~~
twic
Literally _thousands_ of hours of playing ping-pong went into these
buildpacks.

------
harikb
> written in Go

I am not sure what this line is adding. It is supposed to add "runtime
support". Is this doing some language specific libraries? But then they do
support various other languages! Why is Go special? or that all language
support is somehow made in Go? Binaries made in Go? May be that should have
been left out for clarity. This is very confusing for me.

~~~
jacques_chester
It may be an insider perspective. Early buildpacks were dominantly written in
Ruby or Bash (one major one was written in Python). The Bash ones were
_awful_. There was a generation after these, but before Paketo, which were
written in Golang. Consolidating the various codebases was a big step forward
and left a deep impression.

~~~
dwillist
Hey, I'm one of the engineers working on this project, and this is exactly
why. Golang is not 'special' just the tool we use to set up your application
configuration & dependencies. We left the Golang reference on the homepage to
try and avoid the 'surprise' factor of realizing the Paketo Buildpacks are not
written using the language support they provide.

~~~
ngngngng
Nitpick, but it's not Golang. It's Go.

------
mappu
Buildpacks are used by Dokku and GitLab AutoDevOps via gliderlabs/herokuish.
Herokuish is a large bash script; the language autodetection can be
inscrutable at times; it has opinions I don't share (e.g. PHP should not
commit composer vendor, and let the buildpack do it); so I switched to
Dockerfiles and don't use it any more.

Is this a replacement for herokuish? Can users use it today in those projects,
or does it first need to become the default in Dokku and Gitlab? How closely
do the environments/behaviours match herokuish?

~~~
josegonzalez
Dokku Maintainer here.

Herokuish defers a lot of this work to the buildpacks.

\- Language autodetection performs the bin/detect script for each buildpack in
order. Last one wins, unless you have a .buildpacks file, in which case we use
the multi-buildpack executor. Not sure how it can be more... scrutable, but
happy to hear suggestions (my github email in my HN profile has an email for
contact)

\- Besides bundling Heroku's official buildpacks (as it's meant to provide a
compatibility layer with Heroku), herokuish doesn't have any opinions on your
source code structure. If the official Heroku buildpack doesn't do what you
think it should, you can definitely fork it and change the behavior (or even
pull request it so others can benefit).

I can't speak to any specific Cloud-Native Buildpack (CNB) builder such as
paketo, but Dokku should have support for CNB fairly soon (it's one of my top-
priorities re: new development), at which point users will be able to switch
between CNB and Herokuish (rather than force folks to migrate immediately). It
will become the default at some point.

For Gitlab, I believe they are or are planning on providing experimental
support for CNB. You can probably already use it today if you use pack
directly in your pipeline.

As far as how these systems all compare, I wrote a fairly lengthy blog post
comparing the usage of herokuish vs the Cloud Foundry and Heroku builder
systems that might be interesting to read:
[http://dokku.github.io/technology/comparing-
buildpack-v3-to-...](http://dokku.github.io/technology/comparing-
buildpack-v3-to-herokuish)

~~~
kennyGitLab
> For Gitlab, I believe they are or are planning on providing experimental
> support for CNB. You can probably already use it today if you use pack
> directly in your pipeline.

We shipped it today! [https://gitlab.com/gitlab-
org/gitlab/-/issues/25954](https://gitlab.com/gitlab-
org/gitlab/-/issues/25954)

------
tptacek
To what extent is this interesting if I'm not in K8s?

~~~
arjun024
I guess if you have a case for running a html+php+nginx workload, you'd build
your source code with one (or a list) of the buildpacks and create a docker
image and just docker-run it.

------
Gys
> Paketo Buildpacks build images that run on Kubernetes and any other Cloud
> Native platform.

------
nagyv
You can try out Paketo with GitLab using CI environment variables:

You can try it out today using environment variables in your CI job.

Example:

\- AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED: 1 \-
AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER: gcr.io/paketo-buildpacks/builder:base

------
slow_donkey
>How are images built with Paketo Buildpacks different from Docker images?
Unlike Docker images, images built from Paketo Buildpacks are OCI compliant.

Can someone explain why this is significant - I'm struggling to wrap my head
around the why

~~~
sclevine
The OCI image format is a standardization of the Docker v2 image format, but
they are generally compatible and interchangeable. That FAQ entry is
misleading and slipped past the engineering team working on the project. Just
removed it :)

------
atarian
Looks like a replacement for Dockerfiles.

