Update to libcnb 0.21, Buildpack API 0.10 and switch from stacks to targets #197
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A
libcnb.rs
release supports a single Buildpack API version, so whenever we update to a libcnb release that now implements a newer Buildpack API version, we must switch to that version in the buildpack at the same time.This change updates the buildpack to libcnb 0.21.0, which requires both a switch to Buildpack API 0.10, a switch from stacks to targets, and also some adjustments for layer API changes.
As part of the switch from stacks to targets, the buildpack now consumes the Python runtime from the new S3 location/filenames (that use distro name/version in the URL instead of stack ID), which were added in:
heroku/heroku-buildpack-python#1567
The new archives also now use Zstandard (aka zstd) for compression instead of gzip, which results in a faster download due to the smaller archive size (for example, the Ubuntu 22.04 Python 3.12.3 AMD64 archive was 26% smaller) as well as faster decompression. This required switching from the flate2 crate to the zstd crate.
A side-effect of switching to the new S3 files is that the archives for Python 3.7 are no longer available, since I intentionally did not build them given that Python 3.7 is EOL. As such, this change also drops support for Python 3.7 (something that the classic buildpack has already done, and would have been done here already if it were not for being blocked on #8).
The switch to targets unblocks Heroku-24/multi-architecture support, which will be handled in a later PR.
Closes #192.
Closes #194.
GUS-W-15261168.