Paketo Buildpacks | Blog
2021 Paketo Buildpacks Roadmap
We’re not even at the one year anniversary of the Paketo Buildpacks launch, but we’ve already got so much to celebrate 🎉. 2020 was a busy year for the Paketo Buildpacks core development team. Looking back on the last year, a few highlights stand out:
- Establishing our project governance and RFC process
- Moving all project tooling to Github-based workflows
- Building out a foundational set of buildpacks for some of the most popular languages including Java, Node.js, .Net Core, Go, and Ruby.
For 2021, one of our most important goals is to align on a community-driven project roadmap. We started a discussion thread at the start of the new year to solicit interest in areas of development for this year and received a lot of responses.
After synthesizing the community responses, we’ve categorized each into three main themes:
- Solidifying Existing Buildpacks
- Expanding the Buildpacks Ecosystem
- Non-production Use Cases
These themes cover a broad range of exciting ideas and opportunities, much too much to cover in a single blog post. And the ideas in each theme aren’t final. We’d love to hear from you about what languages you are using in your applications and how we can support them with buildpacks.
Solidifying Existing Buildpacks
A lot of the work last year involved modularizing monolithic buildpacks into sets of buildpacks that can be mixed and matched to suit a variety of app configurations. One of the biggest priorities this year is to continue to extend and update our existing buildpacks to accommodate changes in upstream language ecosystems and the Cloud Native Buildpacks project. We’ll also continue working towards modularizing our “non-foundational” buildpacks. This includes work such as re-architecting the PHP buildpack and establishing a Web Server buildpack.
We’ve been working recently to streamline and codify the existing configuration
APIs. Buildpacks will continue to adopt environment variables as the primary
mechanism for their configuration, deprecating the use of buildpack.yml as we
reach a stable API across the existing set of buildpacks. Furthermore, we’ll be
looking into streamlining and extending the log output and “bill of materials”
metadata provided by all buildpacks.
We’ve also recently started to provide a set of standardized common “utility” buildpacks across all language families. These buildpacks solve common use cases such as using Procfiles, setting build/runtime CA Certificates, and setting environment variables on the app image.
Beyond standardizing on our buildpack interfaces, the team will be considering
extensions to existing buildpacks to bring new runtimes and package manager
support. Examples of this type of extension include new Ruby runtimes like
JRuby, as well as functionality to generate code during the build process such
as using go generate.
Expanding the Buildpack Ecosystem
Beyond solidifying the set of existing buildpacks, we want to continue to grow the overall buildpack ecosystem to support new developers and use cases.
A huge part of growing the ecosystem involves building out new buildpacks. We’re already starting to build out better support for Python, and are looking into how we can support new use cases like function platforms. We’re looking to see where we should next invest in new language ecosystems. Some ideas range from Typescript and Swift to Nim and Pony.
An equally important part of growing the ecosystem involves engaging with the community. We plan to focus on community outreach to inform you of what is happening day-to-day, and also gather feedback about what we should be doing next. We’ll be focusing on improving documentation, reference materials, and tutorials. And we’ll be looking for ways to increase the discoverability of the project and its buildpacks.
Non-production Use Cases
We’d like to think that our buildpacks run great in production environments (let us know if they don’t 😄). We want to go a bit further and start looking into how we can improve the buildpack experience beyond production environments.
We’ll be looking into developing buildpacks and integrations that support non-production use cases, and working with CNB project to propose any API changes to accommodate these workflows. We hope to see buildpacks integrate with IDEs and local-development frameworks, expose and enable in-container debugging, and support running test suites while integrating with CI/CD platforms.
Summary
We have a lot lined up for 2021 and welcome new contributors! Please join the discussion to tell us what matters to you.