Update trimesh requirement from >=4.12.2 to >=5.0.0 in /services/data - #281
Open
dependabot[bot] wants to merge 1 commit into
Open
Update trimesh requirement from >=4.12.2 to >=5.0.0 in /services/data#281dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Updates the requirements on [trimesh](https://github.com/mikedh/trimesh) to permit the latest version. - [Release notes](https://github.com/mikedh/trimesh/releases) - [Commits](mikedh/trimesh@4.12.2...5.0.0) --- updated-dependencies: - dependency-name: trimesh dependency-version: 5.0.0 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
|
Strix is installed on this repository, but we couldn't run this PR security review because this workspace's trial has ended. Add a card to resume code reviews here. So far, Strix has reviewed 28 pull requests, surfaced 3 security issues (1 critical/high) and blocked 2 risky merges across this workspace. |
ibuilder
added a commit
that referenced
this pull request
Aug 18, 2026
… CI installs Five npm dev-dependency upgrades, applied together and verified as ONE state: eslint 10.8.0 -> 10.8.1, globals 17.7 -> 17.11, happy-dom 20.8.9 -> 20.11.2, typescript-eslint 8.65 -> 8.67, vite 8.1.5 -> 8.2.1 (dependabot #278 #280 #283 #285 #287). Applied in one commit rather than merged one by one because all five rewrite package-lock.json and would have conflicted pairwise. DEPENDABOT COULD NOT SEE THE WHOLE PICTURE. The ROOT workspace declares vite, eslint and happy-dom too; dependabot only opened PRs against apps/web. So merging them as-is would have changed less than they claimed: * eslint would have stayed on the root's 10.8.0 - hoisted, so the apps/web bump was a NO-OP for linting, the very tool the bump exists to update; * vite would have been installed TWICE - root's exact 8.1.5 against web's exact 8.2.1, forcing a nested second copy. Both roots are aligned; all five now resolve to single hoisted copies at the intended versions, confirmed by reading node_modules rather than the manifest. There is also an `overrides` block pinning eslint repo-wide that dependabot never touches. The first edit landed on IT instead of the devDependency - the same key lives in both sections and a count-limited replace takes whichever comes first. npm rejected it loudly (EOVERRIDE), which is the good case. Both now read 10.8.1 and are asserted equal. toolchainDocs.test.ts then caught the third thing: docs/engineering/web-standards.md still said "eslint 10.8.0". A governed doc whose versions are asserted against the manifest - and whose own comment records that both versions there were wrong for weeks once before. THE SEVEN PYTHON PRs ARE NOT MERGED HERE, deliberately. CI installs from services/api/requirements.lock with --require-hashes, NOT requirements.txt, and those PRs only raise >= floors: * #289 manifold3d, #286 fastapi, #282 shapely, #284 bandit - the lock already pins versions satisfying the new floors; safe, purely making the declaration honest. * #277 numpy, #281 trimesh, #288 boto3 - raise the floor ABOVE what the lock pins (2.5.1, 4.12.2, 1.43.46). test_lock_satisfies_requirements.py guards exactly this and was mutation-tested by simulating #281. Merging without a lock regeneration reds main - and CI would still install the old versions, so a green run would prove nothing about trimesh 5. Web typecheck + lint clean, 1651/1651, build OK. Backend 608/608 (the one failure in the first run was test_changelog_current doing its job: version bumped before this entry existed). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ibuilder
added a commit
that referenced
this pull request
Aug 18, 2026
Four Python floor bumps applied (dependabot #289 manifold3d, #286 fastapi, #282 shapely, #284 bandit). Each raises a >= floor to a version the lock ALREADY pins, so nothing about what installs changes - the declaration simply stops understating what the project requires. test_lock_satisfies_requirements: 50 floors, 110 pins. The other three are refused. #277 numpy (lock 2.5.1), #281 trimesh (4.12.2, a major) and #288 boto3 (1.43.46) raise the floor ABOVE the lock. Two independent reasons: the lock gate would go red (mutation-tested by simulating #281, which fails naming the package, both versions and the line), and CI installs from requirements.lock with --require-hashes, so merging them would produce a green run that tested the OLD versions. A floor bump is a claim about what is required; only a lock regeneration changes what is USED. Two things the mapping turned up, both from checking rather than assuming: * services/api/requirements.txt DOES NOT EXIST. The source is requirements.in, compiled to requirements.lock. A first pass looking for the .txt found nothing and would have read as "these packages are undeclared". * shapely is declared in TWO files - requirements.in at >=2.0 and services/data/requirements.txt at >=2.1.2. Reading the wrong one makes #282 look already applied. Edits are line-anchored and assert exactly one match, so a floor like >=2.0 cannot silently match inside >=2.0.1. Backend 608/608; all five dependency gates pass (lock-satisfies, licence-lock, lock-advisories, licence-allowlist, vendor-drift). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
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 trimesh to permit the latest version.
Release notes
Sourced from trimesh's releases.
Commits
cdb90ebRelease: Minimum Python 3.10 (#2568)aaccf0brename rng -> randoma4d3e3fremove overpromising read_capped8494e02upgraded ruff has new opinions66de43fsimplify rtree check449627eperf(proximity): batch nearby_faces r-tree queries when rtree supports it (#2...8101a4cPass dtype through in random_color (#2581)4be0f74Pass dtype through in random_color176d12eperf(proximity): split batched hits with numpy641cfbeperf(proximity): vectorize nearby faces when rtree supports itDependabot 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 rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill 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 versionwill 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 dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)