Skip to content
New issue

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

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

Already on GitHub? # to your account

Bump alpine default tag to 3.21 #11157

Merged
merged 1 commit into from
Feb 7, 2025

Conversation

samypr100
Copy link
Collaborator

Summary

Alpine 3.21 has been released for a few months and it's now being used officially under alpine based python images, hence our python-alpine based images has been using 3.21 since uv 0.5.8 under the hood.

This could arguably be breaking as we're dropping alpine3.20 top-level tag, so it could be a good candidate for 0.6.0.

Alternatively, we can keep support for 3.20 and make this non-breaking by simply repointing alpine to now be 3.21 and keeping the 3.20 tag around.

@konstin konstin added this to the v0.6.0 milestone Feb 2, 2025
@charliermarsh charliermarsh added releases Related to building and distributing release artifacts of uv breaking A breaking change labels Feb 5, 2025
Copy link
Member

@zanieb zanieb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just waiting for 0.6

Copy link
Member

@konstin konstin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@zanieb zanieb changed the base branch from main to tracking/060 February 7, 2025 20:44
@zanieb zanieb merged commit f64ea11 into astral-sh:tracking/060 Feb 7, 2025
78 checks passed
@zanieb zanieb mentioned this pull request Feb 7, 2025
charliermarsh pushed a commit that referenced this pull request Feb 7, 2025
## Summary

Alpine 3.21 has been released for a few months and it's now being used
officially under `alpine` based [python
images](https://hub.docker.com/_/python), hence our python-alpine based
images has been using 3.21 since uv 0.5.8 under the hood.

This could arguably be `breaking` as we're dropping alpine3.20 top-level
tag, so it could be a good candidate for 0.6.0.

Alternatively, we can keep support for 3.20 and make this non-breaking
by simply repointing alpine to now be 3.21 and keeping the 3.20 tag
around.
@samypr100 samypr100 deleted the update-alpine-docker-tag branch February 8, 2025 15:41
charliermarsh pushed a commit that referenced this pull request Feb 10, 2025
## Summary

Alpine 3.21 has been released for a few months and it's now being used
officially under `alpine` based [python
images](https://hub.docker.com/_/python), hence our python-alpine based
images has been using 3.21 since uv 0.5.8 under the hood.

This could arguably be `breaking` as we're dropping alpine3.20 top-level
tag, so it could be a good candidate for 0.6.0.

Alternatively, we can keep support for 3.20 and make this non-breaking
by simply repointing alpine to now be 3.21 and keeping the 3.20 tag
around.
Gankra pushed a commit that referenced this pull request Feb 12, 2025
## Summary

Alpine 3.21 has been released for a few months and it's now being used
officially under `alpine` based [python
images](https://hub.docker.com/_/python), hence our python-alpine based
images has been using 3.21 since uv 0.5.8 under the hood.

This could arguably be `breaking` as we're dropping alpine3.20 top-level
tag, so it could be a good candidate for 0.6.0.

Alternatively, we can keep support for 3.20 and make this non-breaking
by simply repointing alpine to now be 3.21 and keeping the 3.20 tag
around.
zanieb pushed a commit that referenced this pull request Feb 13, 2025
Alpine 3.21 has been released for a few months and it's now being used
officially under `alpine` based [python
images](https://hub.docker.com/_/python), hence our python-alpine based
images has been using 3.21 since uv 0.5.8 under the hood.

This could arguably be `breaking` as we're dropping alpine3.20 top-level
tag, so it could be a good candidate for 0.6.0.

Alternatively, we can keep support for 3.20 and make this non-breaking
by simply repointing alpine to now be 3.21 and keeping the 3.20 tag
around.
zanieb pushed a commit that referenced this pull request Feb 13, 2025
Alpine 3.21 has been released for a few months and it's now being used
officially under `alpine` based [python
images](https://hub.docker.com/_/python), hence our python-alpine based
images has been using 3.21 since uv 0.5.8 under the hood.

This could arguably be `breaking` as we're dropping alpine3.20 top-level
tag, so it could be a good candidate for 0.6.0.

Alternatively, we can keep support for 3.20 and make this non-breaking
by simply repointing alpine to now be 3.21 and keeping the 3.20 tag
around.
zanieb pushed a commit that referenced this pull request Feb 13, 2025
Alpine 3.21 has been released for a few months and it's now being used
officially under `alpine` based [python
images](https://hub.docker.com/_/python), hence our python-alpine based
images has been using 3.21 since uv 0.5.8 under the hood.

This could arguably be `breaking` as we're dropping alpine3.20 top-level
tag, so it could be a good candidate for 0.6.0.

Alternatively, we can keep support for 3.20 and make this non-breaking
by simply repointing alpine to now be 3.21 and keeping the 3.20 tag
around.
tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request Feb 17, 2025
This MR contains the following updates:

| Package | Update | Change |
|---|---|---|
| [astral-sh/uv](https://github.com/astral-sh/uv) | minor | `0.5.31` -> `0.6.0` |

MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot).

**Proposed changes to behavior should be submitted there as MRs.**

---

### Release Notes

<details>
<summary>astral-sh/uv (astral-sh/uv)</summary>

### [`v0.6.0`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#060)

[Compare Source](astral-sh/uv@0.5.31...0.6.0)

There have been 31 releases and 1135 pull requests since [0.5.0](https://github.com/astral-sh/uv/releases/tag/0.5.0), our last release with breaking changes. As before, we've accumulated various changes that improve correctness and user experience, but could break some workflows. This release contains those changes; many have been marked as breaking out of an abundance of caution. We expect most users to be able to upgrade without making changes.

##### Breaking changes

-   **Create `main.py` instead of `hello.py` in `uv init`** ([#&#8203;10369](astral-sh/uv#10369))

    Previously, `uv init` created a `hello.py` sample file. Now, `uv init` will create `main.py` instead — which aligns with expectations from user feedback. The `--bare` option can be used to avoid creating the file altogether.

-   **Respect `UV_PYTHON` in `uv python install`** ([#&#8203;11487](astral-sh/uv#11487))

    Previously, `uv python install` did not read this environment variable; now it does. We believe this matches user expectations, however, this will take priority over `.python-version` files which could be considered breaking.

-   **Set `UV` to the uv executable path** ([#&#8203;11326](astral-sh/uv#11326))

    When uv spawns a subprocess, it will now have the `UV` environment variable set to the `uv` binary path. This change is breaking if you are setting the `UV` environment variable yourself, as we will overwrite its value.

    Additionally, this change requires marking the uv Rust entrypoint (`uv::main`) as `unsafe` to avoid unsoundness — this is only relevant if you are invoking uv using Rust. See the [Rust documentation](https://doc.rust-lang.org/std/env/fn.set_var.html#safety) for details about the safety of updating a process' environment.

-   **Error on non-existent extras, e.g., in `uv sync`** ([#&#8203;11426](astral-sh/uv#11426))

    Previously, uv would silently ignore non-existent extras requested on the command-line (e.g., via `uv sync --extra foo`). This is *generally* correct behavior when resolving requests for package extras, because an extra may be present on one compatible version of a package but not another. However, this flexibility doesn't need to apply to the local project and it's less surprising to error here.

-   **Error on missing dependency groups when `--frozen` is provided** ([#&#8203;11499](astral-sh/uv#11499))

    Previously, uv would not validate that the requested dependency groups were present in the lockfile when the `--frozen` flag was used. Now, an error will be raised if a requested dependency group is not present.

-   **Change `-p` to a `--python` alias in `uv pip compile`** ([#&#8203;11486](astral-sh/uv#11486))

    In `uv pip compile`, `-p` was an alias for `--python-version` while everywhere else in uv's interface it is an alias for `--python`. Additionally, `uv pip compile` did not respect the `UV_PYTHON` environment variable. Now, the semantics of this flag have been updated for parity with the rest of the CLI.

    However, `--python-version` is unique: if we cannot find an interpreter with the given version, we will not fail. Instead, we'll use an alternative interpreter and override its version tags with the requested version during package resolution. This behavior is retained here for backwards compatibility, `--python <version>` / `-p <version>` will not fail if the version cannot be found. However, if a specific interpreter is requested, e.g., with `--python <path>` or `--python pypy`, and cannot be found — uv will exit with an error.

    The breaking changes here are that `UV_PYTHON` is respected and `--python <version>` will no longer fail if the version cannot be found.

-   **Bump `alpine` default tag to 3.21 for derived Docker images** ([#&#8203;11157](astral-sh/uv#11157))

    Alpine 3.21 was released in Dec 2024 and is used in the official Alpine-based Python images. Our `uv:python3.x-alpine` images have been using 3.21 since uv v0.5.8. However, now the the `uv:alpine` image will use 3.21 instead of 3.20 and `uv:alpine3.20` will no longer be updated.

-   **Use files instead of junctions on Windows** ([#&#8203;11269](astral-sh/uv#11269))

    Previously, we used junctions for atomic replacement of cache entries on Windows. Now, we use a file with a pointer to the cache entry instead. This resolves various edge-case behaviors with junctions. These files are only intended to be consumed by uv and the cache version has been bumped. We do not think this change will affect workflows.

##### Stabilizations

-   **`uv publish` is no longer in preview** ([#&#8203;11032](astral-sh/uv#11032))

    This does not come with any behavior changes. You will no longer see an experimental warning when using `uv publish`. See the linked pull request for a report on the stabilization.

##### Enhancements

-   Support `--active` for PEP 723 script environments ([#&#8203;11433](astral-sh/uv#11433))
-   Add `revision` to the lockfile to allow backwards-compatible metadata changes ([#&#8203;11500](astral-sh/uv#11500))

##### Bug fixes

-   Avoid reading metadata from `.egg-info` files ([#&#8203;11395](astral-sh/uv#11395))
-   Include archive bucket version in archive pointers ([#&#8203;11306](astral-sh/uv#11306))
-   Omit lockfile version when additional fields are dynamic ([#&#8203;11468](astral-sh/uv#11468))
-   Respect executable name in `uvx --from tool@latest` ([#&#8203;11465](astral-sh/uv#11465))

##### Documentation

-   The `CHANGELOG.md` is now split into separate files for each "major" version to fix rendering ([#&#8203;11510](astral-sh/uv#11510))

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this MR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box

---

This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xNzAuMSIsInVwZGF0ZWRJblZlciI6IjM5LjE3MC4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
loic-lescoat pushed a commit to loic-lescoat/uv that referenced this pull request Mar 2, 2025
Alpine 3.21 has been released for a few months and it's now being used
officially under `alpine` based [python
images](https://hub.docker.com/_/python), hence our python-alpine based
images has been using 3.21 since uv 0.5.8 under the hood.

This could arguably be `breaking` as we're dropping alpine3.20 top-level
tag, so it could be a good candidate for 0.6.0.

Alternatively, we can keep support for 3.20 and make this non-breaking
by simply repointing alpine to now be 3.21 and keeping the 3.20 tag
around.
MichaReiser pushed a commit to astral-sh/ruff that referenced this pull request Mar 10, 2025
## Summary

Alpine 3.21 has been released for a few months and `uv` has already
migrated in astral-sh/uv#11157
MichaReiser pushed a commit to astral-sh/ruff that referenced this pull request Mar 10, 2025
## Summary

Alpine 3.21 has been released for a few months and `uv` has already
migrated in astral-sh/uv#11157
MichaReiser pushed a commit to astral-sh/ruff that referenced this pull request Mar 13, 2025
## Summary

Alpine 3.21 has been released for a few months and `uv` has already
migrated in astral-sh/uv#11157
MichaReiser pushed a commit to astral-sh/ruff that referenced this pull request Mar 13, 2025
## Summary

Alpine 3.21 has been released for a few months and `uv` has already
migrated in astral-sh/uv#11157
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
breaking A breaking change releases Related to building and distributing release artifacts of uv
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants