Bump soupsieve from 2.8.3 to 2.8.4

[dependabot]

Bumps soupsieve from 2.8.3 to 2.8.4.

Release notes

Sourced from soupsieve's releases.

2.8.4

• FIX: Fix another inefficient attribute pattern (@​mauriceng98).
• FIX: Limit total number of selectors processed in a pattern to prevent massive selector requests (@​mauriceng98).

Commits

• 28108ab Limit excessive selectors
• ef18872 Fix test for Windows
• eb43976 Merge commit from fork
• 3a661b2 Fix typo in pseudo-classes.md (#294)
• 0cb533d Update hatchling version requirement in pyproject.toml (#290)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[rtibblesbot]

🔵 Review posted

Last updated: 2026-07-10 22:46 UTC

[rtibblesbot]

PR #689 is titled "Bump soupsieve from 2.8.3 to 2.8.4," but the lockfile does the opposite and should not be merged as-is.

Package (claimed): soupsieve 2.8.3 → 2.8.4 (patch, transitive)
Package (actual effect): beautifulsoup4 4.8.2 → 4.6.3 (minor downgrade to a 2018 release, production dep); soupsieve removed entirely (grep -c soupsieve uv.lock → 0). Version 2.8.4 never appears.

Mechanism: bs4 only started depending on soupsieve in 4.7.0. The resolver dropped bs4 to 4.6.3 (the floor of beautifulsoup4>=4.6.3,<4.9.0 in pyproject.toml), which predates soupsieve — so soupsieve was pruned rather than bumped. This loses everything in bs4 4.7/4.8, including the modern soupsieve CSS-selector engine.

Breaking changes: the intended soupsieve 2.8.4 bump is a trivial patch (two efficiency fixes, no API changes). The realized change is a high-impact production regression, not the patch it claims to be.

Marker churn: of 658 changed lines only one package version actually changes; the rest is a whole-file re-resolution adding platform_python_implementation == 'CPython' and reworked python_full_version ranges across most packages. This indicates the lock was regenerated under a different uv version/environment than main, which is what let the resolver collapse bs4 to its floor.

CI: Windows 3.9–3.13 passing; Ubuntu/macOS pending. Green CI only shows the code still runs against bs4 4.6.3 — it does not make the change correct.

Recommendation: REQUEST_CHANGES / recreate. Regenerate the lock with a uv version matching main so beautifulsoup4 stays at its highest allowed version (4.8.2) and soupsieve is retained and bumped to 2.8.4, without the file-wide marker rewrite. Practically: @dependabot recreate, or close and let a corrected bump replace it.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Ran a dependency-update review pipeline over the version bump:

• Classified the bump by semver (patch / minor / major) and dependency type (production vs. development)
• Extracted the changelog and release notes across the version range
• Assessed compatibility with this project's usage and whether any code changes are required
• Treated CI as the primary safety net
• Scaled the review depth to the update's risk
• Chose the verdict from semver risk, changelog findings, and CI status