SDK: fromFedoraImage/fromAlpineImage/fromArchImage helpers - #1612
Conversation
…ge helpers Customer-facing delivery surface for multi-distro template support (server side: e2b-dev/infra#3381). Mirrors the existing Debian-family convenience helpers (fromDebianImage/fromUbuntuImage/...) in both the JS and Python SDKs: - fromFedoraImage(variant='latest') -> fedora:<variant> - fromAlpineImage(variant='latest') -> alpine:<variant> - fromArchImage(variant='latest') -> archlinux:<variant>
🦋 Changeset detectedLatest commit: e2e5011 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
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 |
PR SummaryLow Risk Overview The JS implementation defaults Fedora to Reviewed by Cursor Bugbot for commit e2e5011. Bugbot is set up for automated code reviews on this repo. Configure here. |
Package ArtifactsBuilt from 991af73. Download artifacts from this workflow run. JS SDK ( npm install ./e2b-2.36.2-feat-multi-distro-base-image-helpers.0.tgzCLI ( npm install ./e2b-cli-2.16.1-feat-multi-distro-base-image-helpers.0.tgzPython SDK ( pip install ./e2b-2.35.0+feat.multi.distro.base.image.helpers-py3-none-any.whl |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8e39f9bb79
ℹ️ 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
LGTM — minor nit on the missing changeset noted inline, otherwise this is a clean, low-risk addition.
Extended reasoning...
Overview
Adds three new builder methods (fromFedoraImage/fromAlpineImage/fromArchImage in JS, from_fedora_image/from_alpine_image/from_arch_image in Python) that mirror the existing fromUbuntuImage/fromDebianImage pattern exactly — each just delegates to fromImage()/from_image() with a distro-prefixed tag string and a default variant. Both SDKs are updated in lockstep per CLAUDE.md's cross-SDK parity requirement, TypeScript interface docs are updated to match, and unit tests cover explicit and default variants for all three methods in JS, Python sync, and Python async.
Security risks
None. These methods don't touch auth, credentials, or registry config — they only construct a plain public-registry image string (e.g. fedora:42) that flows into the same from_image/fromImage path already used by the pre-existing Debian/Ubuntu helpers.
Level of scrutiny
Low. This is a mechanical, additive change that copies an established, well-tested pattern with zero new logic branches, no altered control flow in existing methods, and no changes to the build/serialization pipeline. Both SDKs were updated together as required, and tests were added for each new method.
Other factors
The only finding is a nit (missing changeset), already surfaced independently by changeset-bot on the PR and trivial to fix with a single pnpm changeset call before release — it doesn't affect runtime correctness of the shipped code. No outstanding unresolved reviewer comments exist on the PR.
mishushakov
left a comment
There was a problem hiding this comment.
would pin the versions for reproducible builds and remove the tests
- changeset now bumps @e2b/python-sdk as well as e2b; the Python helpers shipped in the same PR and would not have been released otherwise - fromFedoraImage/from_fedora_image defaults to fedora:42 and fromAlpineImage/from_alpine_image to alpine:3.22 so builds stay reproducible instead of following a moving latest tag; both verified booting on real KVM - fromArchImage stays on latest: Arch is rolling and provisioning runs pacman -Syu, so a pinned tag would not change the built result - drop the client-side dockerfile-string tests; the build is worth verifying on the backend instead
819a893 to
5fca8ac
Compare
Heads-up:
|
| run | test |
|---|---|
| 1 | sync/sandbox_sync/test_network.py::test_allow_takes_precedence_over_deny |
| 2 | sync/sandbox_sync/test_network.py::test_deny_specific_ip |
| 3 | async/sandbox_async/test_network.py::test_update_network_clears_existing_rules |
Always 1 failed, 806 passed, 58 skipped.
Why it is not this PR:
Production / Python SDK Testspasses on both ubuntu-22.04 and windows-latest, andStaging / windows-latestpasses. Only Staging/ubuntu fails.- This branch touches
packages/js-sdk/src/template/{index,types}.ts,packages/python-sdk/e2b/template/main.py(three helper defaults + docstrings), the changeset, and deletes three dockerfile-string test files. It does not touchtest_network.pyor anything in the sandbox networking path. - The check was green at
819a8937f; the only change since was a commit-message rewrite to dropCo-Authored-Bytrailers for the CLA — the tree hash is byte-identical.
Likely a transient TLS/egress issue against staging rather than a test bug, though test_network.py has needed flake mitigation before (#1456, "add wait for status for public traffic network tests"). Flagging in case it is worth a look independently of this PR — it will cost roughly one random failure per run to anything gated on that check.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ca27970355
ℹ️ 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".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
LGTM — the changeset gap I flagged earlier is fixed (now bumps both e2b and @e2b/python-sdk), and the three new helpers just delegate to the existing fromImage/from_image following the same pattern as the other distro helpers.
What was reviewed: the new fromFedoraImage/fromAlpineImage/fromArchImage (and Python equivalents) delegation logic, the pinned-tag defaults (fedora:42, alpine:3.22) vs. the deliberate latest for the rolling-release Arch image, and the JS type declarations. Checked the fromArchImage('base-devel') docstring example — not a real issue.
Extended reasoning...
Overview
This PR adds three new base-image convenience helpers (fromFedoraImage/fromAlpineImage/fromArchImage in JS, from_fedora_image/from_alpine_image/from_arch_image in Python) to the Template builder in both SDKs. Each is a one-line wrapper that delegates to the existing fromImage/from_image method with a distro-specific tag string, mirroring the pattern already used by fromDebianImage/fromUbuntuImage/fromPythonImage/etc. The diff also updates the JS TemplateFromImage interface docs and adds a changeset covering both e2b and @e2b/python-sdk.
Security risks
None. These helpers only construct a string passed to the existing, already-reviewed fromImage/from_image implementation — no new parsing, network calls, credential handling, or input validation paths are introduced.
Level of scrutiny
Low. This is additive, mechanical API surface that exactly follows an established pattern used five times already in the same file. The only cross-cutting concern (a missing changeset, which would have silently prevented the Python SDK from actually shipping the change) was raised in my prior review and has since been fixed in commit 819a893 — the changeset now bumps both packages.
Other factors
A human reviewer (mishushakov) also reviewed this PR in detail and requested changes (pin Fedora/Alpine tags for reproducibility, drop the tautological unit tests, fix the changeset scope) — all of which the author addressed in 819a893, with clear rationale recorded for why Arch intentionally stays on latest. The one CI failure on the Staging Python suite was investigated by the author and shown to be a pre-existing, unrelated network-test flake (re-run three times, three different failing tests, tree hash unchanged across the last commit).
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e2e5011. Configure here.
Python `from_fedora_image` defaulted to `fedora:42` (end-of-life) and `from_alpine_image` to `alpine:3.22`, while JS already pinned `fedora:44`/`alpine:3.24` — the same call produced a different base image per SDK. Aligns Python; also fixes the JS type docs, which still named the old defaults. ```python Template().from_fedora_image() # fedora:44 (was fedora:42) Template().from_alpine_image() # alpine:3.24 (was alpine:3.22) ``` Follow-up to #1612; both defaults are still unreleased.

Adds the non-Debian base-image helpers to both SDKs, mirroring
fromUbuntuImage/fromDebianImage/etc.:fromFedoraImage,fromAlpineImage,fromArchImage(from_*_imagein Python). Customer-facing half of infra #3381 — the engine already boots these families, but they were reachable only through the genericfromImage().Per review the client-side helper tests were removed — they only asserted the generated
FROMstring. Build coverage lives in the orchestrator's distro build tests.Docs: e2b-dev/docs#313.