Skip to content

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

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/uv/packages/code-interpreter-python/uv-940ece5b2b
Open

chore(deps-dev): bump the uv group across 3 directories with 1 update#1965
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/uv/packages/code-interpreter-python/uv-940ece5b2b

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Oct 9, 2026 •
edited by devin-ai-integration Bot
Loading

Copy link
Copy Markdown
Contributor

Bumps the uv group with 1 update in the /packages/code-interpreter-python directory: datamodel-code-generator.
Bumps the uv group with 1 update in the /packages/desktop-python directory: datamodel-code-generator.
Bumps the uv group with 1 update in the /packages/python-sdk directory: datamodel-code-generator.

Updates datamodel-code-generator from 0.64.0 to 0.81.0

Release notes

Sourced from datamodel-code-generator's releases.

0.81.0

Breaking Changes

Code Generation Changes

  • Undeclared required keys now retained in variant runtime validation - When combining --read-only-write-only-model-type request/response variants with --schema-validator-type runtime validators, generated models now keep runtime validation rules for required keys that are not declared as properties (for example keys required via additionalProperties or if/then/else), whereas these rules were previously dropped from the variant models. Regenerated Request and Response models therefore enforce stricter validation and may reject payloads that the previously generated validators accepted (#4055)

What's Changed

Full Changelog: datamodel-code-generator/datamodel-code-generator@0.80.0...0.81.0

0.80.0

Breaking Changes

Code Generation Changes

  • Python union annotations preserve unsupported member types - When generating from Python input models, unions containing members such as Callable retain each member type and the original union order instead of repeating the first non-null type. Regenerated annotations change for the affected unions and nested containers. (#3947)
  • Optional nested factories require a callable empty constructor - With --use-default-factory-for-optional-nested-models, an optional child with required constructor fields, including inherited fields, keeps its normal None or UNSET default instead of receiving a factory that fails when called without arguments. (#3953)
  • Safe frozen set items use native Pydantic hash generation - Safely hashable frozen Pydantic v2 models used as set or frozenset items rely on the native hash in place of the explicit identity-hash assignment. Mutable models and models outside the supported safe cases retain the previous generated hash behavior. (#4025)
  • GraphQL msgspec typename fields retain separate inherited slots - For affected GraphQL inheritance collisions, generated models keep inherited synthetic typename slots separate from colliding child user fields, which receive distinct Python names while retaining their wire aliases. Python attribute names in these affected hierarchies can differ from earlier output. (#4045)
  • Constrained root aliases retain their validation - With --use-root-model-type-alias, constraints are retained in the alias where supported; affected roots otherwise use a RootModel class instead of an unconstrained alias. Unconstrained aliases retain their prior form, and an existing custom root-alias template keeps its selection and remains responsible for its own constraints. (#3962)
  • Eligible compound property names use string key types - Eligible string alternatives in propertyNames generate inline constrained string key types instead of nested-model keys. This changes ordinary key annotations for affected schemas; custom schema runtime validators remain conditional on --schema-validator-type pydantic-v2. (#3970)
  • Opt-in schema validators enforce undeclared required names - With --schema-validator-type pydantic-v2, required property names absent from generated fields are checked against the raw object input, including applicable pattern intersections. Payloads missing those required names are rejected where the previous validators accepted them; this fix does not add a validator when the option is disabled. (#3988)
  • Mapped allOf roots retain compatible constraints - For affected allOf roots with an outer format or type mapping, compatible numeric or string constraints are preserved while constraints incompatible with the mapped runtime type are omitted. Regenerated annotations change for these roots and avoid applying incompatible constraints to date, UUID, or other mapped values. (#4043)

... (truncated)

Changelog

Sourced from datamodel-code-generator's changelog.

0.81.0 - 2026-09-14

Breaking Changes

Code Generation Changes

  • Undeclared required keys now retained in variant runtime validation - When combining --read-only-write-only-model-type request/response variants with --schema-validator-type runtime validators, generated models now keep runtime validation rules for required keys that are not declared as properties (for example keys required via additionalProperties or if/then/else), whereas these rules were previously dropped from the variant models. Regenerated Request and Response models therefore enforce stricter validation and may reject payloads that the previously generated validators accepted (#4055)

What's Changed

Full Changelog: datamodel-code-generator/datamodel-code-generator@0.80.0...0.81.0

0.80.0 - 2026-09-12

Breaking Changes

Code Generation Changes

  • Python union annotations preserve unsupported member types - When generating from Python input models, unions containing members such as Callable retain each member type and the original union order instead of repeating the first non-null type. Regenerated annotations change for the affected unions and nested containers. (#3947)
  • Optional nested factories require a callable empty constructor - With --use-default-factory-for-optional-nested-models, an optional child with required constructor fields, including inherited fields, keeps its normal None or UNSET default instead of receiving a factory that fails when called without arguments. (#3953)
  • Safe frozen set items use native Pydantic hash generation - Safely hashable frozen Pydantic v2 models used as set or frozenset items rely on the native hash in place of the explicit identity-hash assignment. Mutable models and models outside the supported safe cases retain the previous generated hash behavior. (#4025)
  • GraphQL msgspec typename fields retain separate inherited slots - For affected GraphQL inheritance collisions, generated models keep inherited synthetic typename slots separate from colliding child user fields, which receive distinct Python names while retaining their wire aliases. Python attribute names in these affected hierarchies can differ from earlier output. (#4045)
  • Constrained root aliases retain their validation - With --use-root-model-type-alias, constraints are retained in the alias where supported; affected roots otherwise use a RootModel class instead of an unconstrained alias. Unconstrained aliases retain their prior form, and an existing custom root-alias template keeps its selection and remains responsible for its own constraints. (#3962)
  • Eligible compound property names use string key types - Eligible string alternatives in propertyNames generate inline constrained string key types instead of nested-model keys. This changes ordinary key annotations for affected schemas; custom schema runtime validators remain conditional on --schema-validator-type pydantic-v2. (#3970)
  • Opt-in schema validators enforce undeclared required names - With --schema-validator-type pydantic-v2, required property names absent from generated fields are checked against the raw object input, including applicable pattern intersections. Payloads missing those required names are rejected where the previous validators accepted them; this fix does not add a validator when the option is disabled. (#3988)
  • Mapped allOf roots retain compatible constraints - For affected allOf roots with an outer format or type mapping, compatible numeric or string constraints are preserved while constraints incompatible with the mapped runtime type are omitted. Regenerated annotations change for these roots and avoid applying incompatible constraints to date, UUID, or other mapped values. (#4043)
  • Eligible property-name alternatives use constrained string keys - For supported propertyNames alternatives combining ordinary string constraints with non-string-only branches, generated dictionary keys use the applicable constrained string type instead of retaining the non-string alternatives. References, complex patterns, and unsupported cases retain the existing fallback. (#4046)

... (truncated)

Commits

Updates datamodel-code-generator from 0.64.0 to 0.81.0

Release notes

Sourced from datamodel-code-generator's releases.

0.81.0

Breaking Changes

Code Generation Changes

  • Undeclared required keys now retained in variant runtime validation - When combining --read-only-write-only-model-type request/response variants with --schema-validator-type runtime validators, generated models now keep runtime validation rules for required keys that are not declared as properties (for example keys required via additionalProperties or if/then/else), whereas these rules were previously dropped from the variant models. Regenerated Request and Response models therefore enforce stricter validation and may reject payloads that the previously generated validators accepted (#4055)

What's Changed

Full Changelog: datamodel-code-generator/datamodel-code-generator@0.80.0...0.81.0

0.80.0

Breaking Changes

Code Generation Changes

  • Python union annotations preserve unsupported member types - When generating from Python input models, unions containing members such as Callable retain each member type and the original union order instead of repeating the first non-null type. Regenerated annotations change for the affected unions and nested containers. (#3947)
  • Optional nested factories require a callable empty constructor - With --use-default-factory-for-optional-nested-models, an optional child with required constructor fields, including inherited fields, keeps its normal None or UNSET default instead of receiving a factory that fails when called without arguments. (#3953)
  • Safe frozen set items use native Pydantic hash generation - Safely hashable frozen Pydantic v2 models used as set or frozenset items rely on the native hash in place of the explicit identity-hash assignment. Mutable models and models outside the supported safe cases retain the previous generated hash behavior. (#4025)
  • GraphQL msgspec typename fields retain separate inherited slots - For affected GraphQL inheritance collisions, generated models keep inherited synthetic typename slots separate from colliding child user fields, which receive distinct Python names while retaining their wire aliases. Python attribute names in these affected hierarchies can differ from earlier output. (#4045)
  • Constrained root aliases retain their validation - With --use-root-model-type-alias, constraints are retained in the alias where supported; affected roots otherwise use a RootModel class instead of an unconstrained alias. Unconstrained aliases retain their prior form, and an existing custom root-alias template keeps its selection and remains responsible for its own constraints. (#3962)
  • Eligible compound property names use string key types - Eligible string alternatives in propertyNames generate inline constrained string key types instead of nested-model keys. This changes ordinary key annotations for affected schemas; custom schema runtime validators remain conditional on --schema-validator-type pydantic-v2. (#3970)
  • Opt-in schema validators enforce undeclared required names - With --schema-validator-type pydantic-v2, required property names absent from generated fields are checked against the raw object input, including applicable pattern intersections. Payloads missing those required names are rejected where the previous validators accepted them; this fix does not add a validator when the option is disabled. (#3988)
  • Mapped allOf roots retain compatible constraints - For affected allOf roots with an outer format or type mapping, compatible numeric or string constraints are preserved while constraints incompatible with the mapped runtime type are omitted. Regenerated annotations change for these roots and avoid applying incompatible constraints to date, UUID, or other mapped values. (#4043)

... (truncated)

Changelog

Sourced from datamodel-code-generator's changelog.

0.81.0 - 2026-09-14

Breaking Changes

Code Generation Changes

  • Undeclared required keys now retained in variant runtime validation - When combining --read-only-write-only-model-type request/response variants with --schema-validator-type runtime validators, generated models now keep runtime validation rules for required keys that are not declared as properties (for example keys required via additionalProperties or if/then/else), whereas these rules were previously dropped from the variant models. Regenerated Request and Response models therefore enforce stricter validation and may reject payloads that the previously generated validators accepted (#4055)

What's Changed

Full Changelog: datamodel-code-generator/datamodel-code-generator@0.80.0...0.81.0

0.80.0 - 2026-09-12

Breaking Changes

Code Generation Changes

  • Python union annotations preserve unsupported member types - When generating from Python input models, unions containing members such as Callable retain each member type and the original union order instead of repeating the first non-null type. Regenerated annotations change for the affected unions and nested containers. (#3947)
  • Optional nested factories require a callable empty constructor - With --use-default-factory-for-optional-nested-models, an optional child with required constructor fields, including inherited fields, keeps its normal None or UNSET default instead of receiving a factory that fails when called without arguments. (#3953)
  • Safe frozen set items use native Pydantic hash generation - Safely hashable frozen Pydantic v2 models used as set or frozenset items rely on the native hash in place of the explicit identity-hash assignment. Mutable models and models outside the supported safe cases retain the previous generated hash behavior. (#4025)
  • GraphQL msgspec typename fields retain separate inherited slots - For affected GraphQL inheritance collisions, generated models keep inherited synthetic typename slots separate from colliding child user fields, which receive distinct Python names while retaining their wire aliases. Python attribute names in these affected hierarchies can differ from earlier output. (#4045)
  • Constrained root aliases retain their validation - With --use-root-model-type-alias, constraints are retained in the alias where supported; affected roots otherwise use a RootModel class instead of an unconstrained alias. Unconstrained aliases retain their prior form, and an existing custom root-alias template keeps its selection and remains responsible for its own constraints. (#3962)
  • Eligible compound property names use string key types - Eligible string alternatives in propertyNames generate inline constrained string key types instead of nested-model keys. This changes ordinary key annotations for affected schemas; custom schema runtime validators remain conditional on --schema-validator-type pydantic-v2. (#3970)
  • Opt-in schema validators enforce undeclared required names - With --schema-validator-type pydantic-v2, required property names absent from generated fields are checked against the raw object input, including applicable pattern intersections. Payloads missing those required names are rejected where the previous validators accepted them; this fix does not add a validator when the option is disabled. (#3988)
  • Mapped allOf roots retain compatible constraints - For affected allOf roots with an outer format or type mapping, compatible numeric or string constraints are preserved while constraints incompatible with the mapped runtime type are omitted. Regenerated annotations change for these roots and avoid applying incompatible constraints to date, UUID, or other mapped values. (#4043)
  • Eligible property-name alternatives use constrained string keys - For supported propertyNames alternatives combining ordinary string constraints with non-string-only branches, generated dictionary keys use the applicable constrained string type instead of retaining the non-string alternatives. References, complex patterns, and unsupported cases retain the existing fallback. (#4046)

... (truncated)

Commits

Updates datamodel-code-generator from 0.64.0 to 0.81.0

Release notes

Sourced from datamodel-code-generator's releases.

0.81.0

Breaking Changes

Code Generation Changes

  • Undeclared required keys now retained in variant runtime validation - When combining --read-only-write-only-model-type request/response variants with --schema-validator-type runtime validators, generated models now keep runtime validation rules for required keys that are not declared as properties (for example keys required via additionalProperties or if/then/else), whereas these rules were previously dropped from the variant models. Regenerated Request and Response models therefore enforce stricter validation and may reject payloads that the previously generated validators accepted (#4055)

What's Changed

Full Changelog: datamodel-code-generator/datamodel-code-generator@0.80.0...0.81.0

0.80.0

Breaking Changes

Code Generation Changes

  • Python union annotations preserve unsupported member types - When generating from Python input models, unions containing members such as Callable retain each member type and the original union order instead of repeating the first non-null type. Regenerated annotations change for the affected unions and nested containers. (#3947)
  • Optional nested factories require a callable empty constructor - With --use-default-factory-for-optional-nested-models, an optional child with required constructor fields, including inherited fields, keeps its normal None or UNSET default instead of receiving a factory that fails when called without arguments. (#3953)
  • Safe frozen set items use native Pydantic hash generation - Safely hashable frozen Pydantic v2 models used as set or frozenset items rely on the native hash in place of the explicit identity-hash assignment. Mutable models and models outside the supported safe cases retain the previous generated hash behavior. (#4025)
  • GraphQL msgspec typename fields retain separate inherited slots - For affected GraphQL inheritance collisions, generated models keep inherited synthetic typename slots separate from colliding child user fields, which receive distinct Python names while retaining their wire aliases. Python attribute names in these affected hierarchies can differ from earlier output. (#4045)
  • Constrained root aliases retain their validation - With --use-root-model-type-alias, constraints are retained in the alias where supported; affected roots otherwise use a RootModel class instead of an unconstrained alias. Unconstrained aliases retain their prior form, and an existing custom root-alias template keeps its selection and remains responsible for its own constraints. (#3962)
  • Eligible compound property names use string key types - Eligible string alternatives in propertyNames generate inline constrained string key types instead of nested-model keys. This changes ordinary key annotations for affected schemas; custom schema runtime validators remain conditional on --schema-validator-type pydantic-v2. (#3970)
  • Opt-in schema validators enforce undeclared required names - With --schema-validator-type pydantic-v2, required property names absent from generated fields are checked against the raw object input, including applicable pattern intersections. Payloads missing those required names are rejected where the previous validators accepted them; this fix does not add a validator when the option is disabled. (#3988)
  • Mapped allOf roots retain compatible constraints - For affected allOf roots with an outer format or type mapping, compatible numeric or string constraints are preserved while constraints incompatible with the mapped runtime type are omitted. Regenerated annotations change for these roots and avoid applying incompatible constraints to date, UUID, or other mapped values. (#4043)

... (truncated)

Changelog

Sourced from datamodel-code-generator's changelog.

0.81.0 - 2026-09-14

Breaking Changes

Code Generation Changes

  • Undeclared required keys now retained in variant runtime validation - When combining --read-only-write-only-model-type request/response variants with --schema-validator-type runtime validators, generated models now keep runtime validation rules for required keys that are not declared as properties (for example keys required via additionalProperties or if/then/else), whereas these rules were previously dropped from the variant models. Regenerated Request and Response models therefore enforce stricter validation and may reject payloads that the previously generated validators accepted (#4055)

What's Changed

Full Changelog: datamodel-code-generator/datamodel-code-generator@0.80.0...0.81.0

0.80.0 - 2026-09-12

Breaking Changes

Code Generation Changes

  • Python union annotations preserve unsupported member types - When generating from Python input models, unions containing members such as Callable retain each member type and the original union order instead of repeating the first non-null type. Regenerated annotations change for the affected unions and nested containers. (#3947)
  • Optional nested factories require a callable empty constructor - With --use-default-factory-for-optional-nested-models, an optional child with required constructor fields, including inherited fields, keeps its normal None or UNSET default instead of receiving a factory that fails when called without arguments. (#3953)
  • Safe frozen set items use native Pydantic hash generation - Safely hashable frozen Pydantic v2 models used as set or frozenset items rely on the native hash in place of the explicit identity-hash assignment. Mutable models and models outside the supported safe cases retain the previous generated hash behavior. (#4025)
  • GraphQL msgspec typename fields retain separate inherited slots - For affected GraphQL inheritance collisions, generated models keep inherited synthetic typename slots separate from colliding child user fields, which receive distinct Python names while retaining their wire aliases. Python attribute names in these affected hierarchies can differ from earlier output. (#4045)
  • Constrained root aliases retain their validation - With --use-root-model-type-alias, constraints are retained in the alias where supported; affected roots otherwise use a RootModel class instead of an unconstrained alias. Unconstrained aliases retain their prior form, and an existing custom root-alias template keeps its selection and remains responsible for its own constraints. (#3962)
  • Eligible compound property names use string key types - Eligible string alternatives in propertyNames generate inline constrained string key types instead of nested-model keys. This changes ordinary key annotations for affected schemas; custom schema runtime validators remain conditional on --schema-validator-type pydantic-v2. (#3970)
  • Opt-in schema validators enforce undeclared required names - With --schema-validator-type pydantic-v2, required property names absent from generated fields are checked against the raw object input, including applicable pattern intersections. Payloads missing those required names are rejected where the previous validators accepted them; this fix does not add a validator when the option is disabled. (#3988)
  • Mapped allOf roots retain compatible constraints - For affected allOf roots with an outer format or type mapping, compatible numeric or string constraints are preserved while constraints incompatible with the mapped runtime type are omitted. Regenerated annotations change for these roots and avoid applying incompatible constraints to date, UUID, or other mapped values. (#4043)
  • Eligible property-name alternatives use constrained string keys - For supported propertyNames alternatives combining ordinary string constraints with non-string-only branches, generated dictionary keys use the applicable constrained string type instead of retaining the non-string alternatives. References, complex patterns, and unsupported cases retain the existing fallback. (#4046)

... (truncated)

Commits

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 <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  • @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  • @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  • @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
  • @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions
    You can disable automated security fix PRs for this repo from the Security Alerts page.

Devin Review

@dependabot
chore(deps-dev): bump the uv group across 3 directories with 1 update
df22b3c 
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).
Bumps the uv group with 1 update in the /packages/desktop-python directory: [datamodel-code-generator](https://github.com/datamodel-code-generator/datamodel-code-generator).
Bumps the uv group with 1 update in the /packages/python-sdk 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)

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)

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
  dependency-group: uv
- dependency-name: datamodel-code-generator
  dependency-version: 0.81.0
  dependency-type: direct:development
  dependency-group: uv
- dependency-name: datamodel-code-generator
  dependency-version: 0.81.0
  dependency-type: direct:development
  dependency-group: uv
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot requested a review from mishushakov as a code owner October 9, 2026 09:35
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file python:uv Pull requests that update python:uv code labels Oct 9, 2026
@cla-bot cla-bot Bot added the cla-signed label Oct 9, 2026
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 9, 2026 •
edited
Loading

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-09T09:37:41.652309Z df22b3c PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@changeset-bot

changeset-bot Bot commented Oct 9, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: df22b3c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@devin-ai-integration

devin-ai-integration Bot commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

I didn't add a changeset to PR #1965 because nothing in it changes how a published package behaves.

The PR touches two files:

  • packages/python-sdk/pyproject.toml: bumps datamodel-code-generator from 0.64.0 to 0.81.0. That package is only in the codegen dependency group, which holds local code-generation tools. It isn't in [project].dependencies, so people who install e2b won't get anything different.
  • packages/code-interpreter-python/uv.lock: only the lockfile changes.

I made no commits to the PR.

devin-ai-integration[bot]
devin-ai-integration Bot reviewed Oct 9, 2026
View reviewed changes

@devin-ai-integration devin-ai-integration Bot left a comment

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.

Devin Review found 2 potential issues.

1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)

Devin Review

Comment thread packages/python-sdk/pyproject.toml
"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.

Comment thread packages/python-sdk/pyproject.toml
"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.

🟡 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.

@github-actions

github-actions Bot commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

Package Artifacts

Built from e95462d. Download artifacts from this workflow run.

JS SDK (e2b@2.54.1-dependabot-uv-packages-code-interpreter-python-uv-940ece5b2b.0, with @e2b/dockerfile-utils@0.1.1-dependabot-uv-packages-code-interpreter-python-uv-940ece5b2b.0):

npm install ./e2b-dockerfile-utils-0.1.1-dependabot-uv-packages-code-interpreter-python-uv-940ece5b2b.0.tgz ./e2b-2.54.1-dependabot-uv-packages-code-interpreter-python-uv-940ece5b2b.0.tgz

CLI (@e2b/cli@2.21.2-dependabot-uv-packages-code-interpreter-python-uv-940ece5b2b.0):

npm install ./e2b-cli-2.21.2-dependabot-uv-packages-code-interpreter-python-uv-940ece5b2b.0.tgz

Code Interpreter JS SDK (@e2b/code-interpreter@2.8.3-dependabot-uv-packages-code-interpreter-python-uv-940ece5b2b.0):

npm install ./e2b-code-interpreter-2.8.3-dependabot-uv-packages-code-interpreter-python-uv-940ece5b2b.0.tgz

Desktop JS SDK (@e2b/desktop@2.4.1-dependabot-uv-packages-code-interpreter-python-uv-940ece5b2b.0):

npm install ./e2b-desktop-2.4.1-dependabot-uv-packages-code-interpreter-python-uv-940ece5b2b.0.tgz

Python SDK (e2b==2.54.0+dependabot.uv.packages.code.interpreter.python.uv.940ece5b2b, with e2b-dockerfile-utils==0.1.0+dependabot.uv.packages.code.interpreter.python.uv.940ece5b2b):

pip install ./e2b_dockerfile_utils-0.1.0+dependabot.uv.packages.code.interpreter.python.uv.940ece5b2b-py3-none-any.whl ./e2b-2.54.0+dependabot.uv.packages.code.interpreter.python.uv.940ece5b2b-py3-none-any.whl

Code Interpreter Python SDK (e2b-code-interpreter==2.10.3+dependabot.uv.packages.code.interpreter.python.uv.940ece5b2b):

pip install ./e2b_code_interpreter-2.10.3+dependabot.uv.packages.code.interpreter.python.uv.940ece5b2b-py3-none-any.whl

Desktop Python SDK (e2b-desktop==2.6.1+dependabot.uv.packages.code.interpreter.python.uv.940ece5b2b):

pip install ./e2b_desktop-2.6.1+dependabot.uv.packages.code.interpreter.python.uv.940ece5b2b-py3-none-any.whl

chatgpt-codex-connector[bot]
chatgpt-codex-connector Bot reviewed Oct 9, 2026
View reviewed changes

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: df22b3c280

ℹ️ 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".

Comment thread packages/python-sdk/pyproject.toml
"black==26.3.1",
"e2b-openapi-python-client==0.26.2",
"datamodel-code-generator==0.64.0",
"datamodel-code-generator==0.81.0",

@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 👍 / 👎.

Comment thread packages/python-sdk/pyproject.toml
"black==26.3.1",
"e2b-openapi-python-client==0.26.2",
"datamodel-code-generator==0.64.0",
"datamodel-code-generator==0.81.0",

@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[bot]
claude Bot reviewed Oct 9, 2026
View reviewed changes

@claude claude Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Findings marked 🟡 are optional suggestions and need no follow-up push.

Comment thread packages/python-sdk/pyproject.toml
"black==26.3.1",
"e2b-openapi-python-client==0.26.2",
"datamodel-code-generator==0.64.0",
"datamodel-code-generator==0.81.0",

@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.

Comment thread packages/python-sdk/pyproject.toml
"black==26.3.1",
"e2b-openapi-python-client==0.26.2",
"datamodel-code-generator==0.64.0",
"datamodel-code-generator==0.81.0",

@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.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@devin-ai-integration devin-ai-integration[bot] devin-ai-integration[bot] left review comments
@chatgpt-codex-connector chatgpt-codex-connector[bot] chatgpt-codex-connector[bot] left review comments
@claude claude[bot] claude[bot] left review comments
@mishushakov mishushakov Awaiting requested review from mishushakov mishushakov is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

cla-signed dependencies Pull requests that update a dependency file python:uv Pull requests that update python:uv code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants