3 ms·
+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) a
by hardwaresofton 7y ago
+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 7y agoThanks 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 7y agoNo 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.
- jacques_chester 7y agoCloud 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.
- hardwaresofton 7y agoThanks very much for replying and clearing up my misunderstanding. This makes a lot more sense now and I understand exactly where Packeto sits.
- jacques_chester 7y agoHappy to help.