Paketo: Modular Buildpacks in Go | Hacker News Reader

Paketo: Modular Buildpacks in Go

paketo.io

93 pointskvedurmu31 comments

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.

+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/

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.

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.

Cloud Foundry has had buildpacks for 6 years or so, initially soft forks of Heroku buildpacks (I worked on these for some time).

The standardisation came about because Heroku and Cloud Foundry folks teamed up.

In terms of your specific question: pack is a CLI tool for using buildpacks to generate images. Paketo is a supported collection of such buildpacks. An analogy might be that pack is a compiler, Paketo is a standard library.

Thanks very much for replying and clearing up my misunderstanding. This makes a lot more sense now and I understand exactly where Packeto sits.

Happy to help.

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 ;-)

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

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

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.

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/

Literally thousands of hours of playing ping-pong went into these buildpacks.

> 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.

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.

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.

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

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?

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-...

> 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

> 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.

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

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

To the extent that you run OCI images somewhere and care about (1) what's in them and (2) rapidly updating what's in them.

It’s more about container images than just k8s.

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.

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

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

>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

Docker's v2 image format was the starting point for OCI, which is a later standard (and: actually a standard with multiple implementations, rather than a single implementation).

This is much more noticeable when you run into Docker v1 and Docker v2 images. They're quite different under the hood. In particular it means that OCI images can perform "layer rebasing" and "cross-repository blob mounting". Updating a layer of an image goes from O(n) to O(1).

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 :)

Looks like a replacement for Dockerfiles.

Reply on news.ycombinator.com