deps: update requests requirement from >=2.31 to >=2.34.2 - #637
Open
dependabot[bot] wants to merge 1 commit into
Open
deps: update requests requirement from >=2.31 to >=2.34.2#637dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
area/infra
Contributor
|
Claude Code Review — skipped: PR author 'dependabot[bot]' is not a public member of the 'caura-ai' org |
Member
|
@dependabot recreate |
Updates the requirements on [requests](https://github.com/psf/requests) to permit the latest version. - [Release notes](https://github.com/psf/requests/releases) - [Changelog](https://github.com/psf/requests/blob/main/HISTORY.md) - [Commits](psf/requests@v2.31.0...v2.34.2) --- updated-dependencies: - dependency-name: requests dependency-version: 2.34.2 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/pip/requests-gte-2.34.2
branch
from
July 27, 2026 08:44
7751014 to
bf76c58
Compare
Contributor
|
Claude Code Review — skipped: PR author 'dependabot[bot]' is not a public member of the 'caura-ai' org |
Eldad-Caura
added a commit
that referenced
this pull request
Aug 10, 2026
… to (#740) Sets `versioning-strategy: increase-if-necessary` on the **uv entry only**, so a requirement in `pyproject.toml` is touched only when the new version actually falls outside it. ## Eight open PRs were doing nothing else The default (`increase`) raises the floor on every release even when the range already permits the new version: ``` uvicorn[standard] >=0.51.0,<1 → >=0.52.0,<1 for a version >=0.51.0,<1 already allowed ``` …once per service directory (#692, #693, #694, #695), plus #645, #646, #650, #691. **The `uv.lock` in all four directories was already being updated correctly** — the manifest edit on top was pure churn. Grouping can't absorb them: `update-types` classifies the semver bump of a *resolved version*, and a floor-raise on an already-satisfied range has no such classification. That's precisely why `uv-minor-patch` collapses the lock updates into one PR (#703, *"across 4 directories"*) while these arrive one at a time. ## Why this setting is right here and wrong elsewhere This is the same option I **rejected** for `caura-ops` two days ago, and the distinction is the whole point: | | this repo's `uv` entry | `caura-ops` | |---|---|---| | requirement shape | **capped** — 22 of 30 in `core-api` have an upper bound | open-ended `>=X`, no cap | | is "outside the range" reachable? | **yes** — uvicorn 1.0 vs `<1` still files a PR | never | | effect of this setting | de-duplicates churn | would have **silenced Python updates entirely** | | correct fix | this | commit a lock + switch ecosystem (done 2026-08-09) | ## Deliberately scoped The **`pip` entry in this same file is untouched.** It has mixed open-ended and capped requirements and no committed root lock, so it needs the `caura-ops` treatment and would be actively harmed by this setting. The file comment says exactly that, placed where someone would be tempted to copy the line. Verified the value is valid against the schema and that it landed on the `uv` entry alone — `pip`, both `npm` entries, `github-actions` and `docker` all remain on the default. ## Honest limit, and a cheap test **I could not confirm `increase-if-necessary`'s precise semantics from the docs** — that section of the options reference truncated on three separate fetches. This rests on the option name plus the observed capped-vs-open behaviour across these eight PRs. It's falsifiable next Monday: the scheduled run should produce **lock-only PRs with no `update X requirement from >=A to >=B` titles**. If widenings still appear, my reading is wrong and this is a one-line revert. I'd rather ship it with the test stated than assert it works. ## What to expect The eight open widening PRs become obsolete. Dependabot may supersede them on the next run; if not, they can be closed. The remaining five `caura-memclaw` widenings (#633–#637) come from the `pip` entry and need the separate lockfile change. @claude Signed-off-by: eldad-caura <eldad@caura.ai>
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
1 participant
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.
Updates the requirements on requests to permit the latest version.
Release notes
Sourced from requests's releases.
Changelog
Sourced from requests's changelog.
... (truncated)
Commits
6e83187v2.34.284d10f0Move Request.headers back to Mapping (#7441)b7b549bv2.34.1e511bc7Fix mutability issues with headers input types (#7431)5691f59Update JsonType containers to read-based collections (#7436)2144213Constrain Response.reason to str (#7437)6404f34Fixprepare_bodystream detection for__getattr__-based file wrappers (#7...0b401c7v2.34.086b378dAlign Session.get parameters with requests.get (#7429)a4f9a59Port bpo-39057 to Requests (#7427)