Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Outdated Python version warnings #8

Open
edmorley opened this issue Feb 28, 2023 · 0 comments
Open

Outdated Python version warnings #8

edmorley opened this issue Feb 28, 2023 · 0 comments
Labels
classic buildpack parity Features required for parity with the classic Heroku Python buildpack

Comments

@edmorley
Copy link
Member

We should add support for displaying build log warnings/notices in the following cases:

  1. Using a Python major version that has reached end-of-life upstream, for example Python 3.7 after June 2023.
  2. Using a non-latest Python patch version, for example Python 3.11.1 when 3.11.2 is the latest version.
  3. (Notice only, rather than a warning) When using a still-supported major Python version, but a newer major version is available. For example when using Python 3.10 but Python 3.11 is available. This is something the classic buildpack did not do, and would help reduce the number of users left to migrate once a Python version reaches end-of-life.

Internal tracking epic
@edmorley edmorley added enhancement New feature or request classic buildpack parity Features required for parity with the classic Heroku Python buildpack and removed enhancement New feature or request labels Feb 28, 2023
@edmorley edmorley mentioned this issue May 1, 2024
Merged
edmorley added a commit that referenced this issue May 2, 2024
@edmorley
Update to libcnb 0.21, Buildpack API 0.10 and switch from stacks to t…
fd95924 
…argets (#197)

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 the latest libcnb release, 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.

See:
https://github.com/heroku/libcnb.rs/blob/main/CHANGELOG.md#0210---2024-04-30
https://github.com/buildpacks/spec/releases/tag/buildpack%2Fv0.10
https://github.com/buildpacks/spec/blob/buildpack/0.10/buildpack.md#targets-1
https://docs.rs/zstd/latest/zstd/

Closes #192.
Closes #194.
GUS-W-15261168.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
classic buildpack parity Features required for parity with the classic Heroku Python buildpack
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@edmorley