Dev-iL commented on code in PR #74556:
URL: https://github.com/apache/airflow/pull/74556#discussion_r4512693876
##########
scripts/docker/install_airflow_when_building_images.sh:
##########
@@ -75,6 +201,13 @@ function install_from_sources() {
${extra_sync_flags} --no-binary-package lxml --no-binary-package
xmlsec \
--no-python-downloads --no-managed-python
else
+ set +x
+ if has_providers_excluded_for_python; then
+ # Mirror the frozen path below: a lock that does not yet carry a
new dependency makes the
+ # helper stop with "<name> is not in the lock", so re-lock and
filter again when allowed.
Review Comment:
You're right: `uv export --frozen` exported a stale lock as it stood, and
the failure only came at `uv pip check`. The frozen filtered path now runs `uv
lock --check` before the export. A stale lock is re-locked when
`AIRFLOW_FALLBACK_NO_CONSTRAINTS_INSTALLATION=true` and fails the build before
any install otherwise. The comment now describes this check.
<details>
<summary>Explanation</summary>
I measured the check's exit codes: it exits 1 for a stale or missing lock,
and 2 when it can't check at all, such as a malformed `pyproject.toml`.
- **Exit 1, fallback allowed.** It re-locks, then exports and installs.
- **Exit 1, fallback not allowed.** The build fails before anything is
exported or installed, saying that `uv.lock` doesn't match the dependency
manifests.
- **Any other non-zero.** The build fails with that status before relocking,
whatever the fallback setting, saying the lock could not be checked. A check
that couldn't run doesn't read as a stale lock, the same rule as the probe's
exit codes.
- **Upgrade path.** It re-locks just before, so it doesn't check.
On the real command, adding a dependency to a provider's `pyproject.toml`
without relocking makes `uv lock --check --offline` exit 1 in about half a
second. It exits 0 on the clean tree.
</details>
<details>
<summary>Tests</summary>
`test_frozen_filtered_install_relocks_a_stale_lock_only_when_fallback_is_allowed`
covers five cases, asserting the command order, the exit status and the
message:
- a fresh lock;
- a stale lock with fallback;
- a stale lock without fallback;
- a check that fails to run, with fallback and without.
With the check removed, all five fail. When any failing exit is treated as
stale, the two cases where the check can't run fail.
`test_source_install_selects_path_from_the_probe` asserts that the frozen
path asks for the check and the upgrade path, which has just re-locked,
doesn't. Dropping `allow-relock` from the frozen call fails it and
`test_source_install_follows_the_real_helper`, which asserts that a frozen
build starts with `uv lock --check`.
</details>
---
Drafted-by: Claude Code (Opus 5.5); reviewed by @Dev-iL before posting
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
