Simplify connection config handling in Python SDK

[jakubno]

Several improvements and refactors to the Python SDK's sandbox connection and configuration logic.

The main focus is on making header management more flexible, improving API parameter handling, and simplifying class structures for better maintainability and usability.

Also unifies doc strings

[linear]

E2B-2838 Improve connection config handling in Python SDK

[changeset-bot]

🦋 Changeset detected

Latest commit: 0c03293

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@e2b/python-sdk	Minor

Not sure what this means? Click here to learn what changesets are.

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

[ValentaTomas]

One detail:

• E2B/packages/python-sdk/e2b/sandbox_sync/sandbox_api.py

  Line 249 in 1395b6e

  limits=cls._limits,

• E2B/packages/python-sdk/e2b/sandbox_async/sandbox_api.py

  Line 264 in 1395b6e

  limits=cls._limits,

Here we can use SandboxApiBase._limits as everywhere else too (I forgot this one).

[mishushakov]

I find it looks weird that you have both headers and extra_sandbox_headers
what about?

default_headers = {'User-Agent': 'xxx'}

def __init__(
    headers: Dict[str, str] = {}
):
    self.headers = {**default_headers, **headers}

[ValentaTomas]

@mishushakov Are you asking why we need two sets of headers?

[mishushakov]

@ValentaTomas yes

[ValentaTomas]

We don't want to be sending the "api" headers (like the supabase token) to the sandbox endpoints and we also don't want to send the "sandbox" headers (like the envd access token) to the API, so to prevent mixing them on the requests made from the methods on the Sandbox instance we need two separate sets.

It is possible that it can be handled more elegantly internally, but we are mostly making sure it behaves sanely to the outside now.

[mishushakov]

@jakubno one question - do we still need this? maybe there's a way to better handle this

https://github.com/e2b-dev/E2B/blob/main/packages/python-sdk/e2b/sandbox_async/main.py#L507-L512

[mishushakov]

Can we add docstring for options also?

[ValentaTomas]

@jakubno one question - do we still need this? maybe there's a way to better handle this

https://github.com/e2b-dev/E2B/blob/main/packages/python-sdk/e2b/sandbox_async/main.py#L507-L512

@mishushakov I think this is already removed in this PR as it was both duplicated and there was a bug.

[jakubno]

@jakubno one question - do we still need this? maybe there's a way to better handle this

https://github.com/e2b-dev/E2B/blob/main/packages/python-sdk/e2b/sandbox_async/main.py#L507-L512

It's basically removed, right?

[jakubno]

Can we add docstring for options also?

They are there: https://github.com/e2b-dev/e2b/blob/8ea3448e18edd64c01d7e723cea0ce561a8db633/packages/python-sdk/e2b/connection_config.py#L15

[ValentaTomas]

Can we add docstring for options also?

You mean for the Unpacked option? I'm not sure it will be visible as a separate field.

[jakubno]

Can we add docstring for options also?

You mean for the Unpacked option? I'm not sure it will be visible as a separate field.

I could only add something like

:param opts Additional API request options

But there's a risk it will be obsolete

[cursor]

Bug: API Client Limits Increased After Class Change

The class inheritance change from SandboxApiBase to SandboxBase (and subsequent use of cls._limits) unintentionally increased HTTP connection limits for API client operations in both sync and async sandbox API methods. The limits changed from max_keepalive_connections=10, max_connections=20, keepalive_expiry=20 to max_keepalive_connections=40, max_connections=40, keepalive_expiry=300. This results in significantly larger connection pool sizes and longer timeouts, potentially increasing resource usage.

Additional Locations (1)

• packages/python-sdk/e2b/sandbox_async/sandbox_api.py#L61-L62