Repository navigation
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
Conversation
dependabot
Bot
added
dependencies
|
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Package ArtifactsBuilt from f71965f. Download artifacts from this workflow run. JS SDK ( npm install ./e2b-dockerfile-utils-0.1.2-dependabot-uv-packages-code-interpreter-python-uv-3918a41a67.0.tgz ./e2b-2.56.1-dependabot-uv-packages-code-interpreter-python-uv-3918a41a67.0.tgzCLI ( npm install ./e2b-cli-2.22.1-dependabot-uv-packages-code-interpreter-python-uv-3918a41a67.0.tgzCode Interpreter JS SDK ( npm install ./e2b-code-interpreter-2.9.1-dependabot-uv-packages-code-interpreter-python-uv-3918a41a67.0.tgzDesktop JS SDK ( npm install ./e2b-desktop-2.5.1-dependabot-uv-packages-code-interpreter-python-uv-3918a41a67.0.tgzPython SDK ( pip install ./e2b_dockerfile_utils-0.1.1+dependabot.uv.packages.code.interpreter.python.uv.3918a41a67-py3-none-any.whl ./e2b-2.56.0+dependabot.uv.packages.code.interpreter.python.uv.3918a41a67-py3-none-any.whlCode Interpreter Python SDK ( pip install ./e2b_code_interpreter-2.11.0+dependabot.uv.packages.code.interpreter.python.uv.3918a41a67-py3-none-any.whlDesktop Python SDK ( pip install ./e2b_desktop-2.7.0+dependabot.uv.packages.code.interpreter.python.uv.3918a41a67-py3-none-any.whl |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| "black==26.3.1", | ||
| "e2b-openapi-python-client==0.26.2", | ||
| "datamodel-code-generator==0.64.0", | ||
| "datamodel-code-generator==0.81.0", |
There was a problem hiding this comment.
🔴 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[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 69b38274ea
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| "black==26.3.1", | ||
| "e2b-openapi-python-client==0.26.2", | ||
| "datamodel-code-generator==0.64.0", | ||
| "datamodel-code-generator==0.81.0", |
There was a problem hiding this comment.
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 👍 / 👎.
| "black==26.3.1", | ||
| "e2b-openapi-python-client==0.26.2", | ||
| "datamodel-code-generator==0.64.0", | ||
| "datamodel-code-generator==0.81.0", |
There was a problem hiding this comment.
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 can you jump on the above ^ |
|
@claude maybe you do the job |
Bumps the uv group with 1 update in the /packages/code-interpreter-python directory: [datamodel-code-generator](https://github.com/datamodel-code-generator/datamodel-code-generator). Updates `datamodel-code-generator` from 0.64.0 to 0.81.0 - [Release notes](https://github.com/datamodel-code-generator/datamodel-code-generator/releases) - [Changelog](https://github.com/datamodel-code-generator/datamodel-code-generator/blob/main/CHANGELOG.md) - [Commits](datamodel-code-generator/datamodel-code-generator@0.64.0...0.81.0) --- updated-dependencies: - dependency-name: datamodel-code-generator dependency-version: 0.81.0 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com>
69b3827 to
d9e7eb0
Compare
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
Devin Review found 2 potential issues.
1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)
| "black==26.3.1", | ||
| "e2b-openapi-python-client==0.26.2", | ||
| "datamodel-code-generator==0.64.0", | ||
| "datamodel-code-generator==0.81.0", |
There was a problem hiding this comment.
🔴 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.
Was this helpful? React with 👍 or 👎 to provide feedback.
| "black==26.3.1", | ||
| "e2b-openapi-python-client==0.26.2", | ||
| "datamodel-code-generator==0.64.0", | ||
| "datamodel-code-generator==0.81.0", |
There was a problem hiding this comment.
🟡 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.
Was this helpful? React with 👍 or 👎 to provide feedback.
This branch has not been deployed
1 participant
Bumps the uv group with 1 update in the /packages/code-interpreter-python directory: datamodel-code-generator.
Updates
datamodel-code-generatorfrom 0.64.0 to 0.81.0Release notes
Sourced from datamodel-code-generator's releases.
... (truncated)
Changelog
Sourced from datamodel-code-generator's changelog.
... (truncated)
Commits
be170f7docs: update release benchmark data (#4053)5492ae9Fix payload runtime compatibility (#4063)4401cc7Guard output policy and private parser boundaries (#4060)6c800fcMove output configuration out of parsers (#4059)203d5b2Move output model decisions out of parsers (#4058)45df98aShare JSON Schema reference rewriting across inputs (#4057)19b9465Fix required validation in request and response models (#4055)0966214Fix parser template data reuse (#4054)5e94b8fMerge commit from fork834731ddocs: update release benchmark data (#4052)