Skip to content

chore(deps-dev): bump the uv group across 3 directories with 1 update #1965

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dependabot wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore(deps-dev): bump the uv group across 3 directories with 1 update #1965

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 26 additions & 25 deletions packages/code-interpreter-python/uv.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion packages/python-sdk/pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ dev = [
codegen = [
"black==26.3.1",
"e2b-openapi-python-client==0.26.2",
"datamodel-code-generator==0.64.0",
"datamodel-code-generator==0.81.0",

@devin-ai-integration devin-ai-integration Bot Oct 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 SDK codegen lock retains old generator

With the new pin, uv sync --frozen --group codegen still installs 0.64.0 from the SDK lock. uv sync --locked --group codegen rejects the mismatched lock instead.

Learn more

The SDK maintains its own lockfile, separate from the code-interpreter workspace lockfile. The SDK lock still specifies 0.64.0 for both the generator package and its codegen requirement. Frozen installs trust that lock without checking the project pin, while locked installs require an up-to-date lock. This prevents either mode from using the new pin as intended.

Example: An SDK developer runs uv sync --frozen --group codegen after pulling this PR. The installed generator remains 0.64.0 rather than the requested 0.81.0.

Recommended fix: Refresh and commit packages/python-sdk/uv.lock with uv from the SDK project directory, then check that its codegen metadata and generator package both resolve to 0.81.0.

Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

@devin-ai-integration devin-ai-integration Bot Oct 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 MCP generation differs between local and Docker workflows

After make init, local generate-mcp uses 0.81.0, but codegen.Dockerfile still installs 0.64.0 for make codegen. The two generation workflows can produce different MCP models from the same schema.

Learn more

The SDK codegen group supplies datamodel-codegen to the local generate-mcp target. The root make codegen target instead launches make generate in an image built from codegen.Dockerfile, which installs a separate pin of 0.64.0. Updating only the local pin leaves those two workflows on different generator releases, so outputs may diverge as their generation behavior changes.

Example: A developer runs make init and then uv run make generate-mcp; another runs the root make codegen on the same spec. They invoke versions 0.81.0 and 0.64.0 respectively, despite expecting reproducible generated files.

Recommended fix: Update the datamodel-code-generator pin in codegen.Dockerfile alongside the SDK codegen group, and regenerate and compare the MCP output under the updated image.

Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

@chatgpt-codex-connector chatgpt-codex-connector Bot Oct 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Refresh every workspace lockfile after the dependency bump

The Python SDK is a member of both downstream Python workspaces, but only packages/code-interpreter-python/uv.lock was refreshed; packages/python-sdk/uv.lock:154,229 and packages/desktop-python/uv.lock:326,401 still pin 0.64.0. The Python SDK and desktop workflows run uv sync --locked (python_sdk_tests.yml:48 and desktop_python_tests.yml:48), and uv sync --help defines --locked as asserting that uv.lock remains unchanged, so these jobs will reject the stale locks instead of installing 0.81.0. Regenerate both remaining lockfiles with uv.

AGENTS.md reference: AGENTS.md:L1-L1

Useful? React with 👍 / 👎.

@chatgpt-codex-connector chatgpt-codex-connector Bot Oct 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Keep the containerized codegen pin synchronized

The authoritative make codegen path and the generated-files workflow build codegen.Dockerfile, whose install command still pins datamodel-code-generator==0.64.0 at line 24. Consequently CI continues generating with 0.64.0 while the local codegen group requests 0.81.0, violating the synchronization invariant documented immediately above this change and allowing local and CI generation to produce different output; update the Dockerfile pin alongside this one.

Useful? React with 👍 / 👎.

@claude claude Bot Oct 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Python SDK and desktop CI jobs that run uv sync --locked will fail after merge, because two lockfiles still record the old pin. packages/python-sdk/uv.lock:229 and packages/desktop-python/uv.lock:401 still say datamodel-code-generator ==0.64.0. Only packages/code-interpreter-python/uv.lock was regenerated. Fix: run uv lock in packages/python-sdk and packages/desktop-python as well, so all three locks that include python-sdk's codegen group record ==0.81.0.

Why this was flagged

pyproject.toml:51 now pins datamodel-code-generator==0.81.0. packages/python-sdk/uv.lock:229 still has specifier = "==0.64.0". packages/desktop-python/uv.lock:401 has the same stale specifier through its editable python-sdk dependency. uv sync --locked exits with an error when the lock no longer matches pyproject. CI runs it in .github/workflows/python_sdk_tests.yml:48, typecheck.yml:78, lint.yml:82 and desktop_python_tests.yml:48. On the base branch these locks matched pyproject and those jobs passed. The dependabot description says three directories were bumped, but only code-interpreter-python's lock is in the diff.

Verification: Trigger: any CI job that runs uv sync --locked once this merges. packages/python-sdk/uv.lock:229 still has { name = "datamodel-code-generator", specifier = "==0.64.0" }, and packages/desktop-python/uv.lock:401 has the same stale specifier. On the base commit the specifiers matched pyproject, so this is a regression that breaks the lint, typecheck and test CI jobs.

@claude claude Bot Oct 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 (optional) Code generated locally will now differ from the CI-checked output, because the local tool pin no longer matches the Docker image. The comment at pyproject.toml:44 says these pins mirror codegen.Dockerfile. codegen.Dockerfile:24 still installs datamodel-code-generator==0.64.0, while the codegen group now uses 0.81.0. Fix: bump codegen.Dockerfile:24 to 0.81.0 too, then regenerate with make codegen (e.g. e2b/sandbox/mcp.py) so generated_files.yml passes. Otherwise, keep both pins at 0.64.0.

Why this was flagged

The Makefile:19 make codegen target builds codegen.Dockerfile, which pins datamodel-code-generator==0.64.0 at line 24. The generated_files.yml workflow uses that image to check committed output. After this change, a developer running make init and uv run make generate-* (packages/python-sdk/Makefile:32 runs uv sync --group codegen) gets 0.81.0. 0.81.0 has breaking code-generation changes listed in the 0.80.0/0.81.0 release notes. Regenerated files such as e2b/sandbox/mcp.py can then differ from what CI's 0.64.0 image produces, so the generated-files check fails. On the base branch both pins were 0.64.0, so local and CI output matched, as the comment at pyproject.toml:44 promises.

Verification: packages/python-sdk/pyproject.toml:44 says "Pins mirror codegen.Dockerfile so local output matches CI", and line 51 now reads "datamodel-code-generator==0.81.0". codegen.Dockerfile:24 still runs pip install ... datamodel-code-generator==0.64.0 .... .github/workflows/generated_files.yml:81-136 builds that image, runs make codegen and then git diff to check committed output.

"protoc-gen-connectrpc==0.11.1",
"protoc-gen-py==0.1.1",
]
Expand Down
Loading