Dev-iL commented on code in PR #74556:
URL: https://github.com/apache/airflow/pull/74556#discussion_r4306923538
##########
scripts/docker/install_airflow_when_building_images.sh:
##########
@@ -35,6 +35,55 @@
# shellcheck source=scripts/docker/common.sh
. "$( dirname "${BASH_SOURCE[0]}" )/common.sh"
+function has_providers_excluded_for_python() {
+ local python_minor="${AIRFLOW_PYTHON_VERSION%.*}"
+ PYTHONPATH="$( dirname "${BASH_SOURCE[0]}" )" python3 -c \
+ 'from pathlib import Path; import sys; from filter_ci_install_set
import split_members; sys.exit(not split_members(Path.cwd(), sys.argv[1])[1])' \
+ "${python_minor}"
+}
+
+# uv sync --all-packages installs every workspace member, including providers
excluded for this
+# Python minor and the third-party packages only they need. Resolve the
members that are not excluded
+# for this interpreter, with the lock's pins as constraints, and install
exactly that result.
+function install_workspace_without_excluded_providers() {
+ local python_minor="${AIRFLOW_PYTHON_VERSION%.*}"
+ local work_dir="/tmp/ci-install-set"
+ local python_bin
+ local platform_arch
+ local -a member_dirs=()
+ local -a editable_args=()
+ local member_dir
+ mkdir -p "${work_dir}"
+ python_bin="$(command -v python3)"
+ case "$(uname -m)" in
+ x86_64 | aarch64) platform_arch="$(uname -m)" ;;
+ *)
+ echo "Unsupported architecture for the filtered install: $(uname
-m)"
+ exit 1
+ ;;
+ esac
+ echo
+ echo "${COLOR_BLUE}Installing the workspace without providers excluded for
Python ${python_minor}.${COLOR_RESET}"
+ echo
+ set -x
+ uv export --frozen --all-packages --group ci-image --no-hashes
--no-emit-workspace \
Review Comment:
Good point. Since this started as a build workaround with an invisible side
effect, the desired behavior is now covered by the
`test_filtered_install_never_trades_hash_checking_for_a_successful_build` test.
It checks the three shortcuts:
1. Adding `--no-hashes` to the hashed export.
2. Dropping the hash arguments from the install.
3. No longer passing `--hashes` to the helper.
<details><summary>Detailed AI response</summary>
<p>
Not intended. That was a real regression against `uv sync --frozen`,
including the direct-URL `sphinx-airflow-theme` wheel, and the check is back.
The lock is exported twice: `--no-hashes` for the resolver's constraints
file, and a second export that keeps the hashes. The helper takes `--hashes`
and writes each pin with the export's `--hash` options, so the install runs
under `--require-hashes`. The hash index is keyed by `(name, version)` because
the lock forks packages per interpreter, and a pin the export has no hash for
raises instead of being written unhashed.
Three things only came out of running it against the real lock, none of
which are visible in the diff:
- **`--require-hashes` fails from the workspace root.** uv applies the
root's `constraint-dependencies`, and those are not `==` pinned
(`azure-ai-projects<2.5`), so the whole install is rejected. It needs
`--no-config`. Nothing is lost: these are exact pins installed with
`--no-deps`, and the repo declares no custom index.
- **uv rejects hashes inside a constraints file**, which is why the two
exports stay separate rather than one serving both.
- **uv verifies a hash whenever the requirements file carries one**, with or
without `--require-hashes`. That matters for the temporary
`docker-context-files` path: a locally built wheel is not the artifact the lock
hashed, so the helper has to stop *writing* hashes there too. Dropping
`--require-hashes` alone would still fail on the local wheel. Both arrays are
cleared together.
Verified against the real lock: all 821 requirement entries carry hashes,
`sphinx-airflow-theme` included; an honest set installs; and corrupting every
hash of one entry fails on a cold cache with the expected/computed mismatch.
(Corrupting one of two hashes correctly still passes — they are OR'd.)
</p>
</details>
--
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]
