build(deps): pin pip-compile to the sidecar's Python version via dagger - #1093
Open
mnencia wants to merge 2 commits into
Open
build(deps): pin pip-compile to the sidecar's Python version via dagger#1093mnencia wants to merge 2 commits into
mnencia wants to merge 2 commits into
Conversation
mnencia
added a commit
that referenced
this pull request
Sep 2, 2026
The lockfile had drifted to a Python 3.12 header, not matching the python3.13 venv the sidecar image ships. Regenerated with the correct Python version (see #1093 for the task that automates this going forward); the barman==3.20.0 pin and hashes are unchanged. Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
mnencia
added a commit
that referenced
this pull request
Sep 2, 2026
The lockfile had drifted to a Python 3.12 header, not matching the python3.13 venv the sidecar image ships. Regenerated with the correct Python version (see #1093 for the task that automates this going forward); the barman==3.20.0 pin and hashes are unchanged. Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
NiccoloFei
approved these changes
Sep 2, 2026
The lockfile was regenerated with whatever python3 happened to be on the contributor's machine (3.12), drifting from the python3.13 venv the sidecar image actually ships. Add a task that runs pip-compile inside a debian:trixie-slim dagger container, the same base image family the sidecar build uses, so regeneration always targets the right Python version regardless of the local machine. Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
mnencia
force-pushed
the
pip-compile-python-version
branch
from
September 2, 2026 16:15
79d237c to
4bc8757
Compare
Click 8.5.0 leaves is_flag options without an explicit default as an internal sentinel instead of False. pip-tools 7.6.1 compares that sentinel against the option's value to decide whether to record it in the regenerated file's header, and for a flag with no negative counterpart (like --no-index) it falls back to always emitting the flag name regardless of the actual value. Every fresh install of pip-tools pulls in the latest click and hits this, poisoning the lockfile header with a --no-index that was never requested. Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
mnencia
force-pushed
the
pip-compile-python-version
branch
from
September 2, 2026 16:56
4bc8757 to
4a66d24
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
The sidecar's lockfile (
containers/sidecar-requirements.txt) was being regenerated with whatever python3 happened to be on the contributor's machine, drifting from the python3.13 venv the sidecar image actually ships (this surfaced in #1090, where the lockfile ended up regenerated with Python 3.12). Adds atask pip-compile-sidecarthat runs pip-compile inside a debian:trixie-slim dagger container, the same base image family the sidecar build uses, so regeneration always targets the right Python version regardless of the local machine.