Skip to content

chore(deps-dev): bump datamodel-code-generator from 0.64.0 to 0.81.0 in /packages/code-interpreter-python in the uv group across 1 directory #1975

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
+6 −5
Open

chore(deps-dev): bump datamodel-code-generator from 0.64.0 to 0.81.0 in /packages/code-interpreter-python in the uv group across 1 directory #1975

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
9 changes: 5 additions & 4 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.10.1",
"e2b-openapi-python-client==0.26.2",
"datamodel-code-generator==0.64.0",
"datamodel-code-generator==0.81.0",

@claude claude Bot Oct 12, 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, lint and typecheck CI jobs will fail at install after merge. The codegen pin is now ==0.81.0, but two lockfiles still record ==0.64.0. Those are packages/python-sdk/uv.lock:211 and packages/desktop-python/uv.lock:367, so uv sync --locked reports them out of date. Fix: run uv lock in packages/python-sdk and packages/desktop-python so every lockfile that resolves the python-sdk project records datamodel-code-generator 0.81.0. Only packages/code-interpreter-python/uv.lock was regenerated.

Why this was flagged

packages/python-sdk/pyproject.toml:51 now pins "datamodel-code-generator==0.81.0". packages/python-sdk/uv.lock:211 still has specifier = "==0.64.0" and locks 0.64.0 at lines 136-151. packages/desktop-python/uv.lock:367 also embeds the python-sdk metadata with ==0.64.0. When the metadata no longer matches the lock, uv sync --locked exits with an error saying the lockfile needs updating. That command runs in .github/workflows/python_sdk_tests.yml:48, typecheck.yml:78 and lint.yml:82 (all with working-directory packages/python-sdk), and in desktop_python_tests.yml:48. On the base branch the pins and locks agree, so those jobs install normally. Developers running make generate-mcp locally also get 0.64.0 from the stale python-sdk lock instead of the pinned 0.81.0.

Verification: Trigger: any CI run of the python-sdk or desktop-python jobs on the merged tree. The diff changes packages/python-sdk/pyproject.toml:51 to "datamodel-code-generator==0.81.0", but packages/python-sdk/uv.lock:211 and packages/desktop-python/uv.lock:367 still record specifier = "==0.64.0". So uv sync --locked fails with "lockfile needs to be updated" at .github/workflows/python_sdk_tests.yml:48.

@chatgpt-codex-connector chatgpt-codex-connector Bot Oct 12, 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 Regenerate the Python SDK lockfile

The corresponding packages/python-sdk/uv.lock still records both the package and e2b:codegen requirement as 0.64.0. The Python SDK test, lint, and typecheck workflows run uv sync --locked from this directory; uv sync --help defines --locked as asserting that uv.lock remains unchanged, so these jobs will fail when uv detects that resolving this new pin would alter the lockfile. Regenerate the Python SDK's own lockfile rather than only the code-interpreter workspace lock.

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

Useful? React with 👍 / 👎.

@chatgpt-codex-connector chatgpt-codex-connector Bot Oct 12, 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 Update the Docker codegen pin too

The canonical make codegen path, including .github/workflows/generated_files.yml, builds codegen.Dockerfile, which still installs datamodel-code-generator==0.64.0. Consequently the generated-files check does not exercise 0.81.0 and any fixes from this upgrade are absent from normal repository code generation, while developers using the documented make init path receive 0.81.0. Keep the Docker pin synchronized with this local codegen pin as the surrounding comment requires.

Useful? React with 👍 / 👎.

@devin-ai-integration devin-ai-integration Bot Oct 20, 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.

🔴 Python SDK locked installs fail

After codegen pins 0.81.0, uv sync --locked rejects the SDK's unchanged lockfile, which still pins 0.64.0. Python SDK test, lint, and typecheck jobs stop during dependency installation.

Learn more

The Python SDK has its own lockfile, separate from the code interpreter workspace lockfile. The manifest now requires 0.81.0, while codegen metadata still requires 0.64.0. The Python SDK test workflow uses uv sync --locked, which refuses to update a stale lockfile; lint and typecheck use the same command.

Example: On this branch, a fresh Python SDK checkout runs uv sync --locked: the manifest requests 0.81.0 but its lockfile requests 0.64.0, so installation ends before tests start.

Recommended fix: Regenerate and commit packages/python-sdk/uv.lock with uv lock from the Python SDK directory. Verify uv sync --locked succeeds there.

Devin Review

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

@devin-ai-integration devin-ai-integration Bot Oct 20, 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.

🟡 Local and CI generators use different versions

After make init, local generate-mcp uses 0.81.0 while the CI generator uses 0.64.0. Regenerated MCP models no longer share a pinned toolchain across environments.

Learn more

The Python SDK's codegen group supplies the datamodel-codegen executable for local generation. The generate-mcp target runs it against the tracked MCP schema, while make codegen runs the same target inside an image still pinned to 0.64.0. The repository explicitly keeps those pins aligned so that local generated files match CI; generator releases can change emitted models.

Example: A contributor runs make init and uv run make generate-mcp locally with 0.81.0, then CI runs make codegen with 0.64.0 against the same schema. The two generated files can differ even when the schema has not changed.

Recommended fix: Upgrade the datamodel-code-generator pin in codegen.Dockerfile to 0.81.0 alongside the SDK manifest, regenerate the MCP model with the common toolchain, and verify the generated-files check.

Devin Review

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

"protoc-gen-connectrpc==0.12.1",
"protoc-gen-py==0.6.0",
]
Expand Down
Loading