CDTOOL-1649: Add Python Language Support by posborne · Pull Request #1811 · fastly/cli

posborne · 2026-06-03T19:25:19Z

This change introduces support for Python on Compute to the fastly CLI. For dependencies, after exploring a few different options it was determined that this responsibility was best left to the fastly-compute-py which executes at a better point in time to correctly determine what is part of a Python services dependency graph (in addition to separation of concerns).

The way this dependency information is passed along, dependent on fastly/compute-sdk-python#89, is that the information is written directly into the WASM component as part of the fastly-compute-py build process. Other information may be injected similarly. This approach may be used by other SDKs/tooling in the future should it make sense or be used directly for "Other" languages.

Discussion is ongoing for the approach we'll follow for Python SDK starter templates but that is not included here as they are not available.

Modify the metadata annotation step to read and preserve any fastly_data already embedded in the Wasm binary (e.g. by language-specific build tools like python). This allows build tools to supply package info directly while the CLI dynamically fills in remaining fields (like cloned repository info).

Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

anthony-gomez-fastly · 2026-06-04T15:42:36Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne · 2026-06-04T17:11:18Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Yeah, would definitely be worthwhile I think. I'll work on getting that added.

I also slapped a "DO NOT MERGE YET" label on this for now until the dust settles on our approach for python starter kits and fastly/compute-sdk-python#89. I think this could merge without that PR but I'll want to verify that first.

Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Seeding the whole DataCollection from the binary let a build tool's script_info, machine_info and build_info override fields the CLI owns. The CLI now always writes those itself and reads back only the package list, which is the one thing it cannot collect for Python. The read is also gated on the language reporting no dependencies of its own, so the extra `wasm-tools metadata show` subprocess no longer runs for Rust, Go and JavaScript.

Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

kailan · 2026-08-04T15:06:13Z

Review feedback is addressed across four commits (3bc678f, c97db52, d360125, d54cbf2). Verified end-to-end by building the CLI and running compute build against a real Python project — the missing-constraint path produces the new error and remediation, and the happy path builds pkg/test.tar.gz with correct merged metadata.

Three things worth flagging before this merges:

1. fastly-compute-py dependency metadata is merged but not released. compute-sdk-python#89 landed on main on 2026-06-05, but the latest tag/release is still v0.1.2 (2026-06-03), and PyPI fastly-compute tops out at 0.1.2. There are 5 unreleased commits on main ahead of that tag.

I confirmed this empirically: running uv run fastly-compute-py build against the pinned fastly-compute==0.1.2 in our testdata produces a producers section containing only language, processed-by and sdk — no fastly_data key. So the package_info read-back path in AnnotateWasmBinaryLong is currently dead code against every released version of the build tool. It's correct, just unexercised until an SDK release goes out.

The good news is the shapes line up: dependencies.rs serialises {"package_info":{"packages":{...}}}, and lib.rs pushes it as a processed-by / fastly_data pair — exactly what readExistingPackageInfo parses. So this should light up on its own once the SDK ships, no CLI change needed. Might be worth cutting that release first so we can validate the merge against a real artifact rather than only the mocked unit test.

2. The embedded pkg/config/config.toml has no [language.python] section. Now that a missing toolchain_constraint is a hard error, a stock config makes every Python build fail. This is the same state cpp is in — scripts/config.sh copies .fastly/config.toml over it at release time — so it should resolve itself through the normal release path. Calling it out because the new error makes the consequence louder than it was for cpp, and it's worth confirming the release script covers it.

3. build_test.go tests for Python — TestBuildPython already exists on the branch (gated behind TEST_COMPUTE_BUILD / TEST_COMPUTE_BUILD_PYTHON), so I believe the earlier question about test coverage is resolved. Flagging in case you wanted something broader than what's there.

…age-support # Conflicts: # CHANGELOG.md

anthony-gomez-fastly

LGTM, thanks you two!

### Change summary Fixes [CDTOOL-1707](https://fastly.atlassian.net/browse/CDTOOL-1707). `fastly compute init --language python` reports that no starter kits exist: ``` $ fastly compute init --language python --non-interactive ERROR: no default starter kits configured for this language; please specify a template using the --from flag. ``` Interactively it prints _"No default starter kits are currently configured for this language"_ and falls back to prompting for a template git URL. The starter kits embedded into the CLI binary are injected into `pkg/config/config.toml` at build time by [`./scripts/config.sh`](https://github.com/fastly/cli/blob/main/scripts/config.sh), which holds its own hardcoded list of starter kit repositories. Python language support (#1811) added `[language.python]` to `.fastly/config.toml` and wired Python into `NewLanguages()`, but never added `compute-starter-kit-python-default` to that list — so `kits.Python` is empty and `PromptForStarterKit` takes its "no kits" branch. `[language.python]` is present, so `compute build` is unaffected; the gap is only starter kits. This adds the repository to the list, plus a test asserting that every language offered at the `compute init` prompt has at least one starter kit in the static config, so the same drift is caught for the next language we add. CI generates the config with `make config` before running tests, so the test runs against the real generated config. **Depends on fastly/compute-starter-kit-python-default#6**, which gives the kit a human-readable `name` in its `fastly.toml`. `config.sh` copies that field verbatim into the config, so until it merges the prompt renders `[1] fastly-compute-python-app` rather than `[1] Default starter for Python`. Nothing needs re-landing here once it merges — the config is regenerated on each build — but this PR should not be released before that one. All Submissions: * [x] Have you followed the guidelines in our Contributing document? * [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/fastly/cli/pulls) for the same update/change? ### Changes to Core Features: * [x] Have you written new tests for your core changes, as applicable? * [x] Have you successfully run tests with your changes locally? Verified end-to-end after `make config`: ``` $ fastly compute init --language python --non-interactive ... SUCCESS: Initialized package proj ``` ### User Impact Python users can init a project from the default starter kit instead of having to supply `--from` or paste a git URL. ### Are there any considerations that need to be addressed for release? No breaking changes and no `config_version` bump needed — `NeedsUpdating` already rewrites local configs when the CLI version changes, so existing users pick the new kit up on their next upgrade. 🤖 Generated with [Claude Code](https://claude.com/claude-code) [CDTOOL-1707]: https://fastly.atlassian.net/browse/CDTOOL-1707?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

posborne · 2026-06-03T19:25:19Z

This change introduces support for Python on Compute to the fastly CLI. For dependencies, after exploring a few different options it was determined that this responsibility was best left to the fastly-compute-py which executes at a better point in time to correctly determine what is part of a Python services dependency graph (in addition to separation of concerns).

The way this dependency information is passed along, dependent on fastly/compute-sdk-python#89, is that the information is written directly into the WASM component as part of the fastly-compute-py build process. Other information may be injected similarly. This approach may be used by other SDKs/tooling in the future should it make sense or be used directly for "Other" languages.

Discussion is ongoing for the approach we'll follow for Python SDK starter templates but that is not included here as they are not available.

Modify the metadata annotation step to read and preserve any fastly_data already embedded in the Wasm binary (e.g. by language-specific build tools like python). This allows build tools to supply package info directly while the CLI dynamically fills in remaining fields (like cloned repository info).

Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

anthony-gomez-fastly · 2026-06-04T15:42:36Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne · 2026-06-04T17:11:18Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Yeah, would definitely be worthwhile I think. I'll work on getting that added.

I also slapped a "DO NOT MERGE YET" label on this for now until the dust settles on our approach for python starter kits and fastly/compute-sdk-python#89. I think this could merge without that PR but I'll want to verify that first.

Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Seeding the whole DataCollection from the binary let a build tool's script_info, machine_info and build_info override fields the CLI owns. The CLI now always writes those itself and reads back only the package list, which is the one thing it cannot collect for Python. The read is also gated on the language reporting no dependencies of its own, so the extra `wasm-tools metadata show` subprocess no longer runs for Rust, Go and JavaScript.

Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

kailan · 2026-08-04T15:06:13Z

Review feedback is addressed across four commits (3bc678f, c97db52, d360125, d54cbf2). Verified end-to-end by building the CLI and running compute build against a real Python project — the missing-constraint path produces the new error and remediation, and the happy path builds pkg/test.tar.gz with correct merged metadata.

Three things worth flagging before this merges:

1. fastly-compute-py dependency metadata is merged but not released. compute-sdk-python#89 landed on main on 2026-06-05, but the latest tag/release is still v0.1.2 (2026-06-03), and PyPI fastly-compute tops out at 0.1.2. There are 5 unreleased commits on main ahead of that tag.

I confirmed this empirically: running uv run fastly-compute-py build against the pinned fastly-compute==0.1.2 in our testdata produces a producers section containing only language, processed-by and sdk — no fastly_data key. So the package_info read-back path in AnnotateWasmBinaryLong is currently dead code against every released version of the build tool. It's correct, just unexercised until an SDK release goes out.

The good news is the shapes line up: dependencies.rs serialises {"package_info":{"packages":{...}}}, and lib.rs pushes it as a processed-by / fastly_data pair — exactly what readExistingPackageInfo parses. So this should light up on its own once the SDK ships, no CLI change needed. Might be worth cutting that release first so we can validate the merge against a real artifact rather than only the mocked unit test.

2. The embedded pkg/config/config.toml has no [language.python] section. Now that a missing toolchain_constraint is a hard error, a stock config makes every Python build fail. This is the same state cpp is in — scripts/config.sh copies .fastly/config.toml over it at release time — so it should resolve itself through the normal release path. Calling it out because the new error makes the consequence louder than it was for cpp, and it's worth confirming the release script covers it.

3. build_test.go tests for Python — TestBuildPython already exists on the branch (gated behind TEST_COMPUTE_BUILD / TEST_COMPUTE_BUILD_PYTHON), so I believe the earlier question about test coverage is resolved. Flagging in case you wanted something broader than what's there.

…age-support # Conflicts: # CHANGELOG.md

anthony-gomez-fastly

LGTM, thanks you two!

### Change summary Fixes [CDTOOL-1707](https://fastly.atlassian.net/browse/CDTOOL-1707). `fastly compute init --language python` reports that no starter kits exist: ``` $ fastly compute init --language python --non-interactive ERROR: no default starter kits configured for this language; please specify a template using the --from flag. ``` Interactively it prints _"No default starter kits are currently configured for this language"_ and falls back to prompting for a template git URL. The starter kits embedded into the CLI binary are injected into `pkg/config/config.toml` at build time by [`./scripts/config.sh`](https://github.com/fastly/cli/blob/main/scripts/config.sh), which holds its own hardcoded list of starter kit repositories. Python language support (#1811) added `[language.python]` to `.fastly/config.toml` and wired Python into `NewLanguages()`, but never added `compute-starter-kit-python-default` to that list — so `kits.Python` is empty and `PromptForStarterKit` takes its "no kits" branch. `[language.python]` is present, so `compute build` is unaffected; the gap is only starter kits. This adds the repository to the list, plus a test asserting that every language offered at the `compute init` prompt has at least one starter kit in the static config, so the same drift is caught for the next language we add. CI generates the config with `make config` before running tests, so the test runs against the real generated config. **Depends on fastly/compute-starter-kit-python-default#6**, which gives the kit a human-readable `name` in its `fastly.toml`. `config.sh` copies that field verbatim into the config, so until it merges the prompt renders `[1] fastly-compute-python-app` rather than `[1] Default starter for Python`. Nothing needs re-landing here once it merges — the config is regenerated on each build — but this PR should not be released before that one. All Submissions: * [x] Have you followed the guidelines in our Contributing document? * [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/fastly/cli/pulls) for the same update/change? ### Changes to Core Features: * [x] Have you written new tests for your core changes, as applicable? * [x] Have you successfully run tests with your changes locally? Verified end-to-end after `make config`: ``` $ fastly compute init --language python --non-interactive ... SUCCESS: Initialized package proj ``` ### User Impact Python users can init a project from the default starter kit instead of having to supply `--from` or paste a git URL. ### Are there any considerations that need to be addressed for release? No breaking changes and no `config_version` bump needed — `NeedsUpdating` already rewrites local configs when the CLI version changes, so existing users pick the new kit up on their next upgrade. 🤖 Generated with [Claude Code](https://claude.com/claude-code) [CDTOOL-1707]: https://fastly.atlassian.net/browse/CDTOOL-1707?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

posborne · 2026-06-03T19:25:19Z

This change introduces support for Python on Compute to the fastly CLI. For dependencies, after exploring a few different options it was determined that this responsibility was best left to the fastly-compute-py which executes at a better point in time to correctly determine what is part of a Python services dependency graph (in addition to separation of concerns).

The way this dependency information is passed along, dependent on fastly/compute-sdk-python#89, is that the information is written directly into the WASM component as part of the fastly-compute-py build process. Other information may be injected similarly. This approach may be used by other SDKs/tooling in the future should it make sense or be used directly for "Other" languages.

Discussion is ongoing for the approach we'll follow for Python SDK starter templates but that is not included here as they are not available.

Modify the metadata annotation step to read and preserve any fastly_data already embedded in the Wasm binary (e.g. by language-specific build tools like python). This allows build tools to supply package info directly while the CLI dynamically fills in remaining fields (like cloned repository info).

Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

anthony-gomez-fastly · 2026-06-04T15:42:36Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne · 2026-06-04T17:11:18Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Yeah, would definitely be worthwhile I think. I'll work on getting that added.

I also slapped a "DO NOT MERGE YET" label on this for now until the dust settles on our approach for python starter kits and fastly/compute-sdk-python#89. I think this could merge without that PR but I'll want to verify that first.

Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Seeding the whole DataCollection from the binary let a build tool's script_info, machine_info and build_info override fields the CLI owns. The CLI now always writes those itself and reads back only the package list, which is the one thing it cannot collect for Python. The read is also gated on the language reporting no dependencies of its own, so the extra `wasm-tools metadata show` subprocess no longer runs for Rust, Go and JavaScript.

Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

kailan · 2026-08-04T15:06:13Z

Review feedback is addressed across four commits (3bc678f, c97db52, d360125, d54cbf2). Verified end-to-end by building the CLI and running compute build against a real Python project — the missing-constraint path produces the new error and remediation, and the happy path builds pkg/test.tar.gz with correct merged metadata.

Three things worth flagging before this merges:

1. fastly-compute-py dependency metadata is merged but not released. compute-sdk-python#89 landed on main on 2026-06-05, but the latest tag/release is still v0.1.2 (2026-06-03), and PyPI fastly-compute tops out at 0.1.2. There are 5 unreleased commits on main ahead of that tag.

I confirmed this empirically: running uv run fastly-compute-py build against the pinned fastly-compute==0.1.2 in our testdata produces a producers section containing only language, processed-by and sdk — no fastly_data key. So the package_info read-back path in AnnotateWasmBinaryLong is currently dead code against every released version of the build tool. It's correct, just unexercised until an SDK release goes out.

The good news is the shapes line up: dependencies.rs serialises {"package_info":{"packages":{...}}}, and lib.rs pushes it as a processed-by / fastly_data pair — exactly what readExistingPackageInfo parses. So this should light up on its own once the SDK ships, no CLI change needed. Might be worth cutting that release first so we can validate the merge against a real artifact rather than only the mocked unit test.

2. The embedded pkg/config/config.toml has no [language.python] section. Now that a missing toolchain_constraint is a hard error, a stock config makes every Python build fail. This is the same state cpp is in — scripts/config.sh copies .fastly/config.toml over it at release time — so it should resolve itself through the normal release path. Calling it out because the new error makes the consequence louder than it was for cpp, and it's worth confirming the release script covers it.

3. build_test.go tests for Python — TestBuildPython already exists on the branch (gated behind TEST_COMPUTE_BUILD / TEST_COMPUTE_BUILD_PYTHON), so I believe the earlier question about test coverage is resolved. Flagging in case you wanted something broader than what's there.

…age-support # Conflicts: # CHANGELOG.md

anthony-gomez-fastly

LGTM, thanks you two!

### Change summary Fixes [CDTOOL-1707](https://fastly.atlassian.net/browse/CDTOOL-1707). `fastly compute init --language python` reports that no starter kits exist: ``` $ fastly compute init --language python --non-interactive ERROR: no default starter kits configured for this language; please specify a template using the --from flag. ``` Interactively it prints _"No default starter kits are currently configured for this language"_ and falls back to prompting for a template git URL. The starter kits embedded into the CLI binary are injected into `pkg/config/config.toml` at build time by [`./scripts/config.sh`](https://github.com/fastly/cli/blob/main/scripts/config.sh), which holds its own hardcoded list of starter kit repositories. Python language support (#1811) added `[language.python]` to `.fastly/config.toml` and wired Python into `NewLanguages()`, but never added `compute-starter-kit-python-default` to that list — so `kits.Python` is empty and `PromptForStarterKit` takes its "no kits" branch. `[language.python]` is present, so `compute build` is unaffected; the gap is only starter kits. This adds the repository to the list, plus a test asserting that every language offered at the `compute init` prompt has at least one starter kit in the static config, so the same drift is caught for the next language we add. CI generates the config with `make config` before running tests, so the test runs against the real generated config. **Depends on fastly/compute-starter-kit-python-default#6**, which gives the kit a human-readable `name` in its `fastly.toml`. `config.sh` copies that field verbatim into the config, so until it merges the prompt renders `[1] fastly-compute-python-app` rather than `[1] Default starter for Python`. Nothing needs re-landing here once it merges — the config is regenerated on each build — but this PR should not be released before that one. All Submissions: * [x] Have you followed the guidelines in our Contributing document? * [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/fastly/cli/pulls) for the same update/change? ### Changes to Core Features: * [x] Have you written new tests for your core changes, as applicable? * [x] Have you successfully run tests with your changes locally? Verified end-to-end after `make config`: ``` $ fastly compute init --language python --non-interactive ... SUCCESS: Initialized package proj ``` ### User Impact Python users can init a project from the default starter kit instead of having to supply `--from` or paste a git URL. ### Are there any considerations that need to be addressed for release? No breaking changes and no `config_version` bump needed — `NeedsUpdating` already rewrites local configs when the CLI version changes, so existing users pick the new kit up on their next upgrade. 🤖 Generated with [Claude Code](https://claude.com/claude-code) [CDTOOL-1707]: https://fastly.atlassian.net/browse/CDTOOL-1707?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

posborne · 2026-06-03T19:25:19Z

This change introduces support for Python on Compute to the fastly CLI. For dependencies, after exploring a few different options it was determined that this responsibility was best left to the fastly-compute-py which executes at a better point in time to correctly determine what is part of a Python services dependency graph (in addition to separation of concerns).

The way this dependency information is passed along, dependent on fastly/compute-sdk-python#89, is that the information is written directly into the WASM component as part of the fastly-compute-py build process. Other information may be injected similarly. This approach may be used by other SDKs/tooling in the future should it make sense or be used directly for "Other" languages.

Discussion is ongoing for the approach we'll follow for Python SDK starter templates but that is not included here as they are not available.

Modify the metadata annotation step to read and preserve any fastly_data already embedded in the Wasm binary (e.g. by language-specific build tools like python). This allows build tools to supply package info directly while the CLI dynamically fills in remaining fields (like cloned repository info).

Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

anthony-gomez-fastly · 2026-06-04T15:42:36Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne · 2026-06-04T17:11:18Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Yeah, would definitely be worthwhile I think. I'll work on getting that added.

I also slapped a "DO NOT MERGE YET" label on this for now until the dust settles on our approach for python starter kits and fastly/compute-sdk-python#89. I think this could merge without that PR but I'll want to verify that first.

Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Seeding the whole DataCollection from the binary let a build tool's script_info, machine_info and build_info override fields the CLI owns. The CLI now always writes those itself and reads back only the package list, which is the one thing it cannot collect for Python. The read is also gated on the language reporting no dependencies of its own, so the extra `wasm-tools metadata show` subprocess no longer runs for Rust, Go and JavaScript.

Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

kailan · 2026-08-04T15:06:13Z

Review feedback is addressed across four commits (3bc678f, c97db52, d360125, d54cbf2). Verified end-to-end by building the CLI and running compute build against a real Python project — the missing-constraint path produces the new error and remediation, and the happy path builds pkg/test.tar.gz with correct merged metadata.

Three things worth flagging before this merges:

1. fastly-compute-py dependency metadata is merged but not released. compute-sdk-python#89 landed on main on 2026-06-05, but the latest tag/release is still v0.1.2 (2026-06-03), and PyPI fastly-compute tops out at 0.1.2. There are 5 unreleased commits on main ahead of that tag.

I confirmed this empirically: running uv run fastly-compute-py build against the pinned fastly-compute==0.1.2 in our testdata produces a producers section containing only language, processed-by and sdk — no fastly_data key. So the package_info read-back path in AnnotateWasmBinaryLong is currently dead code against every released version of the build tool. It's correct, just unexercised until an SDK release goes out.

The good news is the shapes line up: dependencies.rs serialises {"package_info":{"packages":{...}}}, and lib.rs pushes it as a processed-by / fastly_data pair — exactly what readExistingPackageInfo parses. So this should light up on its own once the SDK ships, no CLI change needed. Might be worth cutting that release first so we can validate the merge against a real artifact rather than only the mocked unit test.

2. The embedded pkg/config/config.toml has no [language.python] section. Now that a missing toolchain_constraint is a hard error, a stock config makes every Python build fail. This is the same state cpp is in — scripts/config.sh copies .fastly/config.toml over it at release time — so it should resolve itself through the normal release path. Calling it out because the new error makes the consequence louder than it was for cpp, and it's worth confirming the release script covers it.

3. build_test.go tests for Python — TestBuildPython already exists on the branch (gated behind TEST_COMPUTE_BUILD / TEST_COMPUTE_BUILD_PYTHON), so I believe the earlier question about test coverage is resolved. Flagging in case you wanted something broader than what's there.

…age-support # Conflicts: # CHANGELOG.md

anthony-gomez-fastly

LGTM, thanks you two!

### Change summary Fixes [CDTOOL-1707](https://fastly.atlassian.net/browse/CDTOOL-1707). `fastly compute init --language python` reports that no starter kits exist: ``` $ fastly compute init --language python --non-interactive ERROR: no default starter kits configured for this language; please specify a template using the --from flag. ``` Interactively it prints _"No default starter kits are currently configured for this language"_ and falls back to prompting for a template git URL. The starter kits embedded into the CLI binary are injected into `pkg/config/config.toml` at build time by [`./scripts/config.sh`](https://github.com/fastly/cli/blob/main/scripts/config.sh), which holds its own hardcoded list of starter kit repositories. Python language support (#1811) added `[language.python]` to `.fastly/config.toml` and wired Python into `NewLanguages()`, but never added `compute-starter-kit-python-default` to that list — so `kits.Python` is empty and `PromptForStarterKit` takes its "no kits" branch. `[language.python]` is present, so `compute build` is unaffected; the gap is only starter kits. This adds the repository to the list, plus a test asserting that every language offered at the `compute init` prompt has at least one starter kit in the static config, so the same drift is caught for the next language we add. CI generates the config with `make config` before running tests, so the test runs against the real generated config. **Depends on fastly/compute-starter-kit-python-default#6**, which gives the kit a human-readable `name` in its `fastly.toml`. `config.sh` copies that field verbatim into the config, so until it merges the prompt renders `[1] fastly-compute-python-app` rather than `[1] Default starter for Python`. Nothing needs re-landing here once it merges — the config is regenerated on each build — but this PR should not be released before that one. All Submissions: * [x] Have you followed the guidelines in our Contributing document? * [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/fastly/cli/pulls) for the same update/change? ### Changes to Core Features: * [x] Have you written new tests for your core changes, as applicable? * [x] Have you successfully run tests with your changes locally? Verified end-to-end after `make config`: ``` $ fastly compute init --language python --non-interactive ... SUCCESS: Initialized package proj ``` ### User Impact Python users can init a project from the default starter kit instead of having to supply `--from` or paste a git URL. ### Are there any considerations that need to be addressed for release? No breaking changes and no `config_version` bump needed — `NeedsUpdating` already rewrites local configs when the CLI version changes, so existing users pick the new kit up on their next upgrade. 🤖 Generated with [Claude Code](https://claude.com/claude-code) [CDTOOL-1707]: https://fastly.atlassian.net/browse/CDTOOL-1707?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

posborne · 2026-06-03T19:25:19Z

This change introduces support for Python on Compute to the fastly CLI. For dependencies, after exploring a few different options it was determined that this responsibility was best left to the fastly-compute-py which executes at a better point in time to correctly determine what is part of a Python services dependency graph (in addition to separation of concerns).

The way this dependency information is passed along, dependent on fastly/compute-sdk-python#89, is that the information is written directly into the WASM component as part of the fastly-compute-py build process. Other information may be injected similarly. This approach may be used by other SDKs/tooling in the future should it make sense or be used directly for "Other" languages.

Discussion is ongoing for the approach we'll follow for Python SDK starter templates but that is not included here as they are not available.

Modify the metadata annotation step to read and preserve any fastly_data already embedded in the Wasm binary (e.g. by language-specific build tools like python). This allows build tools to supply package info directly while the CLI dynamically fills in remaining fields (like cloned repository info).

Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

anthony-gomez-fastly · 2026-06-04T15:42:36Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne · 2026-06-04T17:11:18Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Yeah, would definitely be worthwhile I think. I'll work on getting that added.

I also slapped a "DO NOT MERGE YET" label on this for now until the dust settles on our approach for python starter kits and fastly/compute-sdk-python#89. I think this could merge without that PR but I'll want to verify that first.

Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Seeding the whole DataCollection from the binary let a build tool's script_info, machine_info and build_info override fields the CLI owns. The CLI now always writes those itself and reads back only the package list, which is the one thing it cannot collect for Python. The read is also gated on the language reporting no dependencies of its own, so the extra `wasm-tools metadata show` subprocess no longer runs for Rust, Go and JavaScript.

Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

kailan · 2026-08-04T15:06:13Z

Review feedback is addressed across four commits (3bc678f, c97db52, d360125, d54cbf2). Verified end-to-end by building the CLI and running compute build against a real Python project — the missing-constraint path produces the new error and remediation, and the happy path builds pkg/test.tar.gz with correct merged metadata.

Three things worth flagging before this merges:

1. fastly-compute-py dependency metadata is merged but not released. compute-sdk-python#89 landed on main on 2026-06-05, but the latest tag/release is still v0.1.2 (2026-06-03), and PyPI fastly-compute tops out at 0.1.2. There are 5 unreleased commits on main ahead of that tag.

I confirmed this empirically: running uv run fastly-compute-py build against the pinned fastly-compute==0.1.2 in our testdata produces a producers section containing only language, processed-by and sdk — no fastly_data key. So the package_info read-back path in AnnotateWasmBinaryLong is currently dead code against every released version of the build tool. It's correct, just unexercised until an SDK release goes out.

The good news is the shapes line up: dependencies.rs serialises {"package_info":{"packages":{...}}}, and lib.rs pushes it as a processed-by / fastly_data pair — exactly what readExistingPackageInfo parses. So this should light up on its own once the SDK ships, no CLI change needed. Might be worth cutting that release first so we can validate the merge against a real artifact rather than only the mocked unit test.

2. The embedded pkg/config/config.toml has no [language.python] section. Now that a missing toolchain_constraint is a hard error, a stock config makes every Python build fail. This is the same state cpp is in — scripts/config.sh copies .fastly/config.toml over it at release time — so it should resolve itself through the normal release path. Calling it out because the new error makes the consequence louder than it was for cpp, and it's worth confirming the release script covers it.

3. build_test.go tests for Python — TestBuildPython already exists on the branch (gated behind TEST_COMPUTE_BUILD / TEST_COMPUTE_BUILD_PYTHON), so I believe the earlier question about test coverage is resolved. Flagging in case you wanted something broader than what's there.

…age-support # Conflicts: # CHANGELOG.md

anthony-gomez-fastly

LGTM, thanks you two!

### Change summary Fixes [CDTOOL-1707](https://fastly.atlassian.net/browse/CDTOOL-1707). `fastly compute init --language python` reports that no starter kits exist: ``` $ fastly compute init --language python --non-interactive ERROR: no default starter kits configured for this language; please specify a template using the --from flag. ``` Interactively it prints _"No default starter kits are currently configured for this language"_ and falls back to prompting for a template git URL. The starter kits embedded into the CLI binary are injected into `pkg/config/config.toml` at build time by [`./scripts/config.sh`](https://github.com/fastly/cli/blob/main/scripts/config.sh), which holds its own hardcoded list of starter kit repositories. Python language support (#1811) added `[language.python]` to `.fastly/config.toml` and wired Python into `NewLanguages()`, but never added `compute-starter-kit-python-default` to that list — so `kits.Python` is empty and `PromptForStarterKit` takes its "no kits" branch. `[language.python]` is present, so `compute build` is unaffected; the gap is only starter kits. This adds the repository to the list, plus a test asserting that every language offered at the `compute init` prompt has at least one starter kit in the static config, so the same drift is caught for the next language we add. CI generates the config with `make config` before running tests, so the test runs against the real generated config. **Depends on fastly/compute-starter-kit-python-default#6**, which gives the kit a human-readable `name` in its `fastly.toml`. `config.sh` copies that field verbatim into the config, so until it merges the prompt renders `[1] fastly-compute-python-app` rather than `[1] Default starter for Python`. Nothing needs re-landing here once it merges — the config is regenerated on each build — but this PR should not be released before that one. All Submissions: * [x] Have you followed the guidelines in our Contributing document? * [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/fastly/cli/pulls) for the same update/change? ### Changes to Core Features: * [x] Have you written new tests for your core changes, as applicable? * [x] Have you successfully run tests with your changes locally? Verified end-to-end after `make config`: ``` $ fastly compute init --language python --non-interactive ... SUCCESS: Initialized package proj ``` ### User Impact Python users can init a project from the default starter kit instead of having to supply `--from` or paste a git URL. ### Are there any considerations that need to be addressed for release? No breaking changes and no `config_version` bump needed — `NeedsUpdating` already rewrites local configs when the CLI version changes, so existing users pick the new kit up on their next upgrade. 🤖 Generated with [Claude Code](https://claude.com/claude-code) [CDTOOL-1707]: https://fastly.atlassian.net/browse/CDTOOL-1707?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

posborne · 2026-06-03T19:25:19Z

This change introduces support for Python on Compute to the fastly CLI. For dependencies, after exploring a few different options it was determined that this responsibility was best left to the fastly-compute-py which executes at a better point in time to correctly determine what is part of a Python services dependency graph (in addition to separation of concerns).

The way this dependency information is passed along, dependent on fastly/compute-sdk-python#89, is that the information is written directly into the WASM component as part of the fastly-compute-py build process. Other information may be injected similarly. This approach may be used by other SDKs/tooling in the future should it make sense or be used directly for "Other" languages.

Discussion is ongoing for the approach we'll follow for Python SDK starter templates but that is not included here as they are not available.

Modify the metadata annotation step to read and preserve any fastly_data already embedded in the Wasm binary (e.g. by language-specific build tools like python). This allows build tools to supply package info directly while the CLI dynamically fills in remaining fields (like cloned repository info).

Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

anthony-gomez-fastly · 2026-06-04T15:42:36Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne · 2026-06-04T17:11:18Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Yeah, would definitely be worthwhile I think. I'll work on getting that added.

I also slapped a "DO NOT MERGE YET" label on this for now until the dust settles on our approach for python starter kits and fastly/compute-sdk-python#89. I think this could merge without that PR but I'll want to verify that first.

Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Seeding the whole DataCollection from the binary let a build tool's script_info, machine_info and build_info override fields the CLI owns. The CLI now always writes those itself and reads back only the package list, which is the one thing it cannot collect for Python. The read is also gated on the language reporting no dependencies of its own, so the extra `wasm-tools metadata show` subprocess no longer runs for Rust, Go and JavaScript.

Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

kailan · 2026-08-04T15:06:13Z

Review feedback is addressed across four commits (3bc678f, c97db52, d360125, d54cbf2). Verified end-to-end by building the CLI and running compute build against a real Python project — the missing-constraint path produces the new error and remediation, and the happy path builds pkg/test.tar.gz with correct merged metadata.

Three things worth flagging before this merges:

1. fastly-compute-py dependency metadata is merged but not released. compute-sdk-python#89 landed on main on 2026-06-05, but the latest tag/release is still v0.1.2 (2026-06-03), and PyPI fastly-compute tops out at 0.1.2. There are 5 unreleased commits on main ahead of that tag.

I confirmed this empirically: running uv run fastly-compute-py build against the pinned fastly-compute==0.1.2 in our testdata produces a producers section containing only language, processed-by and sdk — no fastly_data key. So the package_info read-back path in AnnotateWasmBinaryLong is currently dead code against every released version of the build tool. It's correct, just unexercised until an SDK release goes out.

The good news is the shapes line up: dependencies.rs serialises {"package_info":{"packages":{...}}}, and lib.rs pushes it as a processed-by / fastly_data pair — exactly what readExistingPackageInfo parses. So this should light up on its own once the SDK ships, no CLI change needed. Might be worth cutting that release first so we can validate the merge against a real artifact rather than only the mocked unit test.

2. The embedded pkg/config/config.toml has no [language.python] section. Now that a missing toolchain_constraint is a hard error, a stock config makes every Python build fail. This is the same state cpp is in — scripts/config.sh copies .fastly/config.toml over it at release time — so it should resolve itself through the normal release path. Calling it out because the new error makes the consequence louder than it was for cpp, and it's worth confirming the release script covers it.

3. build_test.go tests for Python — TestBuildPython already exists on the branch (gated behind TEST_COMPUTE_BUILD / TEST_COMPUTE_BUILD_PYTHON), so I believe the earlier question about test coverage is resolved. Flagging in case you wanted something broader than what's there.

…age-support # Conflicts: # CHANGELOG.md

anthony-gomez-fastly

LGTM, thanks you two!

### Change summary Fixes [CDTOOL-1707](https://fastly.atlassian.net/browse/CDTOOL-1707). `fastly compute init --language python` reports that no starter kits exist: ``` $ fastly compute init --language python --non-interactive ERROR: no default starter kits configured for this language; please specify a template using the --from flag. ``` Interactively it prints _"No default starter kits are currently configured for this language"_ and falls back to prompting for a template git URL. The starter kits embedded into the CLI binary are injected into `pkg/config/config.toml` at build time by [`./scripts/config.sh`](https://github.com/fastly/cli/blob/main/scripts/config.sh), which holds its own hardcoded list of starter kit repositories. Python language support (#1811) added `[language.python]` to `.fastly/config.toml` and wired Python into `NewLanguages()`, but never added `compute-starter-kit-python-default` to that list — so `kits.Python` is empty and `PromptForStarterKit` takes its "no kits" branch. `[language.python]` is present, so `compute build` is unaffected; the gap is only starter kits. This adds the repository to the list, plus a test asserting that every language offered at the `compute init` prompt has at least one starter kit in the static config, so the same drift is caught for the next language we add. CI generates the config with `make config` before running tests, so the test runs against the real generated config. **Depends on fastly/compute-starter-kit-python-default#6**, which gives the kit a human-readable `name` in its `fastly.toml`. `config.sh` copies that field verbatim into the config, so until it merges the prompt renders `[1] fastly-compute-python-app` rather than `[1] Default starter for Python`. Nothing needs re-landing here once it merges — the config is regenerated on each build — but this PR should not be released before that one. All Submissions: * [x] Have you followed the guidelines in our Contributing document? * [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/fastly/cli/pulls) for the same update/change? ### Changes to Core Features: * [x] Have you written new tests for your core changes, as applicable? * [x] Have you successfully run tests with your changes locally? Verified end-to-end after `make config`: ``` $ fastly compute init --language python --non-interactive ... SUCCESS: Initialized package proj ``` ### User Impact Python users can init a project from the default starter kit instead of having to supply `--from` or paste a git URL. ### Are there any considerations that need to be addressed for release? No breaking changes and no `config_version` bump needed — `NeedsUpdating` already rewrites local configs when the CLI version changes, so existing users pick the new kit up on their next upgrade. 🤖 Generated with [Claude Code](https://claude.com/claude-code) [CDTOOL-1707]: https://fastly.atlassian.net/browse/CDTOOL-1707?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

posborne · 2026-06-03T19:25:19Z

This change introduces support for Python on Compute to the fastly CLI. For dependencies, after exploring a few different options it was determined that this responsibility was best left to the fastly-compute-py which executes at a better point in time to correctly determine what is part of a Python services dependency graph (in addition to separation of concerns).

The way this dependency information is passed along, dependent on fastly/compute-sdk-python#89, is that the information is written directly into the WASM component as part of the fastly-compute-py build process. Other information may be injected similarly. This approach may be used by other SDKs/tooling in the future should it make sense or be used directly for "Other" languages.

Discussion is ongoing for the approach we'll follow for Python SDK starter templates but that is not included here as they are not available.

Modify the metadata annotation step to read and preserve any fastly_data already embedded in the Wasm binary (e.g. by language-specific build tools like python). This allows build tools to supply package info directly while the CLI dynamically fills in remaining fields (like cloned repository info).

Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

anthony-gomez-fastly · 2026-06-04T15:42:36Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne · 2026-06-04T17:11:18Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Yeah, would definitely be worthwhile I think. I'll work on getting that added.

I also slapped a "DO NOT MERGE YET" label on this for now until the dust settles on our approach for python starter kits and fastly/compute-sdk-python#89. I think this could merge without that PR but I'll want to verify that first.

Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Seeding the whole DataCollection from the binary let a build tool's script_info, machine_info and build_info override fields the CLI owns. The CLI now always writes those itself and reads back only the package list, which is the one thing it cannot collect for Python. The read is also gated on the language reporting no dependencies of its own, so the extra `wasm-tools metadata show` subprocess no longer runs for Rust, Go and JavaScript.

Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

kailan · 2026-08-04T15:06:13Z

Review feedback is addressed across four commits (3bc678f, c97db52, d360125, d54cbf2). Verified end-to-end by building the CLI and running compute build against a real Python project — the missing-constraint path produces the new error and remediation, and the happy path builds pkg/test.tar.gz with correct merged metadata.

Three things worth flagging before this merges:

1. fastly-compute-py dependency metadata is merged but not released. compute-sdk-python#89 landed on main on 2026-06-05, but the latest tag/release is still v0.1.2 (2026-06-03), and PyPI fastly-compute tops out at 0.1.2. There are 5 unreleased commits on main ahead of that tag.

I confirmed this empirically: running uv run fastly-compute-py build against the pinned fastly-compute==0.1.2 in our testdata produces a producers section containing only language, processed-by and sdk — no fastly_data key. So the package_info read-back path in AnnotateWasmBinaryLong is currently dead code against every released version of the build tool. It's correct, just unexercised until an SDK release goes out.

The good news is the shapes line up: dependencies.rs serialises {"package_info":{"packages":{...}}}, and lib.rs pushes it as a processed-by / fastly_data pair — exactly what readExistingPackageInfo parses. So this should light up on its own once the SDK ships, no CLI change needed. Might be worth cutting that release first so we can validate the merge against a real artifact rather than only the mocked unit test.

2. The embedded pkg/config/config.toml has no [language.python] section. Now that a missing toolchain_constraint is a hard error, a stock config makes every Python build fail. This is the same state cpp is in — scripts/config.sh copies .fastly/config.toml over it at release time — so it should resolve itself through the normal release path. Calling it out because the new error makes the consequence louder than it was for cpp, and it's worth confirming the release script covers it.

3. build_test.go tests for Python — TestBuildPython already exists on the branch (gated behind TEST_COMPUTE_BUILD / TEST_COMPUTE_BUILD_PYTHON), so I believe the earlier question about test coverage is resolved. Flagging in case you wanted something broader than what's there.

…age-support # Conflicts: # CHANGELOG.md

anthony-gomez-fastly

LGTM, thanks you two!

### Change summary Fixes [CDTOOL-1707](https://fastly.atlassian.net/browse/CDTOOL-1707). `fastly compute init --language python` reports that no starter kits exist: ``` $ fastly compute init --language python --non-interactive ERROR: no default starter kits configured for this language; please specify a template using the --from flag. ``` Interactively it prints _"No default starter kits are currently configured for this language"_ and falls back to prompting for a template git URL. The starter kits embedded into the CLI binary are injected into `pkg/config/config.toml` at build time by [`./scripts/config.sh`](https://github.com/fastly/cli/blob/main/scripts/config.sh), which holds its own hardcoded list of starter kit repositories. Python language support (#1811) added `[language.python]` to `.fastly/config.toml` and wired Python into `NewLanguages()`, but never added `compute-starter-kit-python-default` to that list — so `kits.Python` is empty and `PromptForStarterKit` takes its "no kits" branch. `[language.python]` is present, so `compute build` is unaffected; the gap is only starter kits. This adds the repository to the list, plus a test asserting that every language offered at the `compute init` prompt has at least one starter kit in the static config, so the same drift is caught for the next language we add. CI generates the config with `make config` before running tests, so the test runs against the real generated config. **Depends on fastly/compute-starter-kit-python-default#6**, which gives the kit a human-readable `name` in its `fastly.toml`. `config.sh` copies that field verbatim into the config, so until it merges the prompt renders `[1] fastly-compute-python-app` rather than `[1] Default starter for Python`. Nothing needs re-landing here once it merges — the config is regenerated on each build — but this PR should not be released before that one. All Submissions: * [x] Have you followed the guidelines in our Contributing document? * [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/fastly/cli/pulls) for the same update/change? ### Changes to Core Features: * [x] Have you written new tests for your core changes, as applicable? * [x] Have you successfully run tests with your changes locally? Verified end-to-end after `make config`: ``` $ fastly compute init --language python --non-interactive ... SUCCESS: Initialized package proj ``` ### User Impact Python users can init a project from the default starter kit instead of having to supply `--from` or paste a git URL. ### Are there any considerations that need to be addressed for release? No breaking changes and no `config_version` bump needed — `NeedsUpdating` already rewrites local configs when the CLI version changes, so existing users pick the new kit up on their next upgrade. 🤖 Generated with [Claude Code](https://claude.com/claude-code) [CDTOOL-1707]: https://fastly.atlassian.net/browse/CDTOOL-1707?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

posborne · 2026-06-03T19:25:19Z

This change introduces support for Python on Compute to the fastly CLI. For dependencies, after exploring a few different options it was determined that this responsibility was best left to the fastly-compute-py which executes at a better point in time to correctly determine what is part of a Python services dependency graph (in addition to separation of concerns).

The way this dependency information is passed along, dependent on fastly/compute-sdk-python#89, is that the information is written directly into the WASM component as part of the fastly-compute-py build process. Other information may be injected similarly. This approach may be used by other SDKs/tooling in the future should it make sense or be used directly for "Other" languages.

Discussion is ongoing for the approach we'll follow for Python SDK starter templates but that is not included here as they are not available.

Modify the metadata annotation step to read and preserve any fastly_data already embedded in the Wasm binary (e.g. by language-specific build tools like python). This allows build tools to supply package info directly while the CLI dynamically fills in remaining fields (like cloned repository info).

Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

anthony-gomez-fastly · 2026-06-04T15:42:36Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne · 2026-06-04T17:11:18Z

is it worth writing any tests in pkg/commands/compute/build_test.go for python?

Yeah, would definitely be worthwhile I think. I'll work on getting that added.

I also slapped a "DO NOT MERGE YET" label on this for now until the dust settles on our approach for python starter kits and fastly/compute-sdk-python#89. I think this could merge without that PR but I'll want to verify that first.

Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Seeding the whole DataCollection from the binary let a build tool's script_info, machine_info and build_info override fields the CLI owns. The CLI now always writes those itself and reads back only the package list, which is the one thing it cannot collect for Python. The read is also gated on the language reporting no dependencies of its own, so the extra `wasm-tools metadata show` subprocess no longer runs for Rust, Go and JavaScript.

Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

kailan · 2026-08-04T15:06:13Z

Review feedback is addressed across four commits (3bc678f, c97db52, d360125, d54cbf2). Verified end-to-end by building the CLI and running compute build against a real Python project — the missing-constraint path produces the new error and remediation, and the happy path builds pkg/test.tar.gz with correct merged metadata.

Three things worth flagging before this merges:

1. fastly-compute-py dependency metadata is merged but not released. compute-sdk-python#89 landed on main on 2026-06-05, but the latest tag/release is still v0.1.2 (2026-06-03), and PyPI fastly-compute tops out at 0.1.2. There are 5 unreleased commits on main ahead of that tag.

I confirmed this empirically: running uv run fastly-compute-py build against the pinned fastly-compute==0.1.2 in our testdata produces a producers section containing only language, processed-by and sdk — no fastly_data key. So the package_info read-back path in AnnotateWasmBinaryLong is currently dead code against every released version of the build tool. It's correct, just unexercised until an SDK release goes out.

The good news is the shapes line up: dependencies.rs serialises {"package_info":{"packages":{...}}}, and lib.rs pushes it as a processed-by / fastly_data pair — exactly what readExistingPackageInfo parses. So this should light up on its own once the SDK ships, no CLI change needed. Might be worth cutting that release first so we can validate the merge against a real artifact rather than only the mocked unit test.

2. The embedded pkg/config/config.toml has no [language.python] section. Now that a missing toolchain_constraint is a hard error, a stock config makes every Python build fail. This is the same state cpp is in — scripts/config.sh copies .fastly/config.toml over it at release time — so it should resolve itself through the normal release path. Calling it out because the new error makes the consequence louder than it was for cpp, and it's worth confirming the release script covers it.

3. build_test.go tests for Python — TestBuildPython already exists on the branch (gated behind TEST_COMPUTE_BUILD / TEST_COMPUTE_BUILD_PYTHON), so I believe the earlier question about test coverage is resolved. Flagging in case you wanted something broader than what's there.

…age-support # Conflicts: # CHANGELOG.md

anthony-gomez-fastly

LGTM, thanks you two!

### Change summary Fixes [CDTOOL-1707](https://fastly.atlassian.net/browse/CDTOOL-1707). `fastly compute init --language python` reports that no starter kits exist: ``` $ fastly compute init --language python --non-interactive ERROR: no default starter kits configured for this language; please specify a template using the --from flag. ``` Interactively it prints _"No default starter kits are currently configured for this language"_ and falls back to prompting for a template git URL. The starter kits embedded into the CLI binary are injected into `pkg/config/config.toml` at build time by [`./scripts/config.sh`](https://github.com/fastly/cli/blob/main/scripts/config.sh), which holds its own hardcoded list of starter kit repositories. Python language support (#1811) added `[language.python]` to `.fastly/config.toml` and wired Python into `NewLanguages()`, but never added `compute-starter-kit-python-default` to that list — so `kits.Python` is empty and `PromptForStarterKit` takes its "no kits" branch. `[language.python]` is present, so `compute build` is unaffected; the gap is only starter kits. This adds the repository to the list, plus a test asserting that every language offered at the `compute init` prompt has at least one starter kit in the static config, so the same drift is caught for the next language we add. CI generates the config with `make config` before running tests, so the test runs against the real generated config. **Depends on fastly/compute-starter-kit-python-default#6**, which gives the kit a human-readable `name` in its `fastly.toml`. `config.sh` copies that field verbatim into the config, so until it merges the prompt renders `[1] fastly-compute-python-app` rather than `[1] Default starter for Python`. Nothing needs re-landing here once it merges — the config is regenerated on each build — but this PR should not be released before that one. All Submissions: * [x] Have you followed the guidelines in our Contributing document? * [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/fastly/cli/pulls) for the same update/change? ### Changes to Core Features: * [x] Have you written new tests for your core changes, as applicable? * [x] Have you successfully run tests with your changes locally? Verified end-to-end after `make config`: ``` $ fastly compute init --language python --non-interactive ... SUCCESS: Initialized package proj ``` ### User Impact Python users can init a project from the default starter kit instead of having to supply `--from` or paste a git URL. ### Are there any considerations that need to be addressed for release? No breaking changes and no `config_version` bump needed — `NeedsUpdating` already rewrites local configs when the CLI version changes, so existing users pick the new kit up on their next upgrade. 🤖 Generated with [Claude Code](https://claude.com/claude-code) [CDTOOL-1707]: https://fastly.atlassian.net/browse/CDTOOL-1707?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

posborne added 3 commits June 3, 2026 14:11

Add support for the Python programming language
c7b818f
Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Avoid panic when prompt language has empty starter kits
5fc35b2
Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

posborne requested a review from a team as a code owner June 3, 2026 19:25

posborne requested a review from anthony-gomez-fastly June 3, 2026 19:25

posborne added 2 commits June 3, 2026 16:32

Address gosec file permission warnings in metadata unit tests
088b021
Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

Update CHANGELOG.md to note Python language addition
dd0ac32

anthony-gomez-fastly reviewed Jun 4, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

Update CHANGELOG.md
c9baae9
Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne added the DO NOT MERGE YET label Jun 4, 2026

posborne added 2 commits June 5, 2026 13:04

test(compute): add build test scenarios for Python language
ac87f1c
Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

Install uv in CI for tests
f3b8e2c

kpfleming changed the title ~~Add Python Language Support~~CDTOOL-1649: Add Python Language SupportJun 15, 2026

Merge branch 'main' into posborne/python-language-support
1e54913

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/init.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/build.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/language_python.go Outdated

kailan added 4 commits August 4, 2026 16:04

Move Python CHANGELOG entry to Unreleased
3bc678f
The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

Drop redundant nil validator in starter kit URL prompt
c97db52
text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Error on missing Python toolchain_constraint
d54cbf2
Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

Merge remote-tracking branch 'origin/main' into posborne/python-langu…
5f12b6f
…age-support # Conflicts: # CHANGELOG.md

kailan removed the DO NOT MERGE YET label Aug 4, 2026

anthony-gomez-fastly approved these changes Aug 4, 2026
View reviewed changes

anthony-gomez-fastly enabled auto-merge (squash) August 4, 2026 15:19

anthony-gomez-fastly merged commit f975ca4 into mainAug 4, 2026
19 of 23 checks passed

anthony-gomez-fastly deleted the posborne/python-language-support branch August 4, 2026 15:25

BrewTestBot mentioned this pull request Aug 4, 2026
fastly 15.5.0 Homebrew/homebrew-core#297065
Merged

kailan mentioned this pull request Aug 7, 2026
[CDTOOL-1707] add Python starter kit to the static config #1877
Merged
4 tasks

posborne mentioned this pull request Aug 12, 2026
Update deps and bump version to 0.1.3 fastly/compute-sdk-python#115
Merged

posborne added 3 commits June 3, 2026 14:11

Add support for the Python programming language
c7b818f
Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Avoid panic when prompt language has empty starter kits
5fc35b2
Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

posborne requested a review from a team as a code owner June 3, 2026 19:25

posborne requested a review from anthony-gomez-fastly June 3, 2026 19:25

posborne added 2 commits June 3, 2026 16:32

Address gosec file permission warnings in metadata unit tests
088b021
Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

Update CHANGELOG.md to note Python language addition
dd0ac32

anthony-gomez-fastly reviewed Jun 4, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

Update CHANGELOG.md
c9baae9
Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne added the DO NOT MERGE YET label Jun 4, 2026

posborne added 2 commits June 5, 2026 13:04

test(compute): add build test scenarios for Python language
ac87f1c
Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

Install uv in CI for tests
f3b8e2c

kpfleming changed the title ~~Add Python Language Support~~CDTOOL-1649: Add Python Language SupportJun 15, 2026

Merge branch 'main' into posborne/python-language-support
1e54913

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/init.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/build.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/language_python.go Outdated

kailan added 4 commits August 4, 2026 16:04

Move Python CHANGELOG entry to Unreleased
3bc678f
The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

Drop redundant nil validator in starter kit URL prompt
c97db52
text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Error on missing Python toolchain_constraint
d54cbf2
Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

Merge remote-tracking branch 'origin/main' into posborne/python-langu…
5f12b6f
…age-support # Conflicts: # CHANGELOG.md

kailan removed the DO NOT MERGE YET label Aug 4, 2026

anthony-gomez-fastly approved these changes Aug 4, 2026
View reviewed changes

anthony-gomez-fastly enabled auto-merge (squash) August 4, 2026 15:19

anthony-gomez-fastly merged commit f975ca4 into mainAug 4, 2026
19 of 23 checks passed

anthony-gomez-fastly deleted the posborne/python-language-support branch August 4, 2026 15:25

BrewTestBot mentioned this pull request Aug 4, 2026
fastly 15.5.0 Homebrew/homebrew-core#297065
Merged

kailan mentioned this pull request Aug 7, 2026
[CDTOOL-1707] add Python starter kit to the static config #1877
Merged
4 tasks

posborne mentioned this pull request Aug 12, 2026
Update deps and bump version to 0.1.3 fastly/compute-sdk-python#115
Merged

posborne added 3 commits June 3, 2026 14:11

Add support for the Python programming language
c7b818f
Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Avoid panic when prompt language has empty starter kits
5fc35b2
Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

posborne requested a review from a team as a code owner June 3, 2026 19:25

posborne requested a review from anthony-gomez-fastly June 3, 2026 19:25

posborne added 2 commits June 3, 2026 16:32

Address gosec file permission warnings in metadata unit tests
088b021
Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

Update CHANGELOG.md to note Python language addition
dd0ac32

anthony-gomez-fastly reviewed Jun 4, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

Update CHANGELOG.md
c9baae9
Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne added the DO NOT MERGE YET label Jun 4, 2026

posborne added 2 commits June 5, 2026 13:04

test(compute): add build test scenarios for Python language
ac87f1c
Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

Install uv in CI for tests
f3b8e2c

kpfleming changed the title ~~Add Python Language Support~~CDTOOL-1649: Add Python Language SupportJun 15, 2026

Merge branch 'main' into posborne/python-language-support
1e54913

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/init.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/build.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/language_python.go Outdated

kailan added 4 commits August 4, 2026 16:04

Move Python CHANGELOG entry to Unreleased
3bc678f
The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

Drop redundant nil validator in starter kit URL prompt
c97db52
text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Error on missing Python toolchain_constraint
d54cbf2
Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

Merge remote-tracking branch 'origin/main' into posborne/python-langu…
5f12b6f
…age-support # Conflicts: # CHANGELOG.md

kailan removed the DO NOT MERGE YET label Aug 4, 2026

anthony-gomez-fastly approved these changes Aug 4, 2026
View reviewed changes

anthony-gomez-fastly enabled auto-merge (squash) August 4, 2026 15:19

anthony-gomez-fastly merged commit f975ca4 into mainAug 4, 2026
19 of 23 checks passed

anthony-gomez-fastly deleted the posborne/python-language-support branch August 4, 2026 15:25

BrewTestBot mentioned this pull request Aug 4, 2026
fastly 15.5.0 Homebrew/homebrew-core#297065
Merged

kailan mentioned this pull request Aug 7, 2026
[CDTOOL-1707] add Python starter kit to the static config #1877
Merged
4 tasks

posborne mentioned this pull request Aug 12, 2026
Update deps and bump version to 0.1.3 fastly/compute-sdk-python#115
Merged

posborne added 3 commits June 3, 2026 14:11

Add support for the Python programming language
c7b818f
Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Avoid panic when prompt language has empty starter kits
5fc35b2
Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

posborne requested a review from a team as a code owner June 3, 2026 19:25

posborne requested a review from anthony-gomez-fastly June 3, 2026 19:25

posborne added 2 commits June 3, 2026 16:32

Address gosec file permission warnings in metadata unit tests
088b021
Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

Update CHANGELOG.md to note Python language addition
dd0ac32

anthony-gomez-fastly reviewed Jun 4, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

Update CHANGELOG.md
c9baae9
Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne added the DO NOT MERGE YET label Jun 4, 2026

posborne added 2 commits June 5, 2026 13:04

test(compute): add build test scenarios for Python language
ac87f1c
Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

Install uv in CI for tests
f3b8e2c

kpfleming changed the title ~~Add Python Language Support~~CDTOOL-1649: Add Python Language SupportJun 15, 2026

Merge branch 'main' into posborne/python-language-support
1e54913

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/init.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/build.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/language_python.go Outdated

kailan added 4 commits August 4, 2026 16:04

Move Python CHANGELOG entry to Unreleased
3bc678f
The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

Drop redundant nil validator in starter kit URL prompt
c97db52
text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Error on missing Python toolchain_constraint
d54cbf2
Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

Merge remote-tracking branch 'origin/main' into posborne/python-langu…
5f12b6f
…age-support # Conflicts: # CHANGELOG.md

kailan removed the DO NOT MERGE YET label Aug 4, 2026

anthony-gomez-fastly approved these changes Aug 4, 2026
View reviewed changes

anthony-gomez-fastly enabled auto-merge (squash) August 4, 2026 15:19

anthony-gomez-fastly merged commit f975ca4 into mainAug 4, 2026
19 of 23 checks passed

anthony-gomez-fastly deleted the posborne/python-language-support branch August 4, 2026 15:25

BrewTestBot mentioned this pull request Aug 4, 2026
fastly 15.5.0 Homebrew/homebrew-core#297065
Merged

kailan mentioned this pull request Aug 7, 2026
[CDTOOL-1707] add Python starter kit to the static config #1877
Merged
4 tasks

posborne mentioned this pull request Aug 12, 2026
Update deps and bump version to 0.1.3 fastly/compute-sdk-python#115
Merged

posborne added 3 commits June 3, 2026 14:11

Add support for the Python programming language
c7b818f
Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Avoid panic when prompt language has empty starter kits
5fc35b2
Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

posborne requested a review from a team as a code owner June 3, 2026 19:25

posborne requested a review from anthony-gomez-fastly June 3, 2026 19:25

posborne added 2 commits June 3, 2026 16:32

Address gosec file permission warnings in metadata unit tests
088b021
Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

Update CHANGELOG.md to note Python language addition
dd0ac32

anthony-gomez-fastly reviewed Jun 4, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

Update CHANGELOG.md
c9baae9
Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne added the DO NOT MERGE YET label Jun 4, 2026

posborne added 2 commits June 5, 2026 13:04

test(compute): add build test scenarios for Python language
ac87f1c
Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

Install uv in CI for tests
f3b8e2c

kpfleming changed the title ~~Add Python Language Support~~CDTOOL-1649: Add Python Language SupportJun 15, 2026

Merge branch 'main' into posborne/python-language-support
1e54913

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/init.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/build.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/language_python.go Outdated

kailan added 4 commits August 4, 2026 16:04

Move Python CHANGELOG entry to Unreleased
3bc678f
The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

Drop redundant nil validator in starter kit URL prompt
c97db52
text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Error on missing Python toolchain_constraint
d54cbf2
Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

Merge remote-tracking branch 'origin/main' into posborne/python-langu…
5f12b6f
…age-support # Conflicts: # CHANGELOG.md

kailan removed the DO NOT MERGE YET label Aug 4, 2026

anthony-gomez-fastly approved these changes Aug 4, 2026
View reviewed changes

anthony-gomez-fastly enabled auto-merge (squash) August 4, 2026 15:19

anthony-gomez-fastly merged commit f975ca4 into mainAug 4, 2026
19 of 23 checks passed

anthony-gomez-fastly deleted the posborne/python-language-support branch August 4, 2026 15:25

BrewTestBot mentioned this pull request Aug 4, 2026
fastly 15.5.0 Homebrew/homebrew-core#297065
Merged

kailan mentioned this pull request Aug 7, 2026
[CDTOOL-1707] add Python starter kit to the static config #1877
Merged
4 tasks

posborne mentioned this pull request Aug 12, 2026
Update deps and bump version to 0.1.3 fastly/compute-sdk-python#115
Merged

posborne added 3 commits June 3, 2026 14:11

Add support for the Python programming language
c7b818f
Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Avoid panic when prompt language has empty starter kits
5fc35b2
Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

posborne requested a review from a team as a code owner June 3, 2026 19:25

posborne requested a review from anthony-gomez-fastly June 3, 2026 19:25

posborne added 2 commits June 3, 2026 16:32

Address gosec file permission warnings in metadata unit tests
088b021
Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

Update CHANGELOG.md to note Python language addition
dd0ac32

anthony-gomez-fastly reviewed Jun 4, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

Update CHANGELOG.md
c9baae9
Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne added the DO NOT MERGE YET label Jun 4, 2026

posborne added 2 commits June 5, 2026 13:04

test(compute): add build test scenarios for Python language
ac87f1c
Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

Install uv in CI for tests
f3b8e2c

kpfleming changed the title ~~Add Python Language Support~~CDTOOL-1649: Add Python Language SupportJun 15, 2026

Merge branch 'main' into posborne/python-language-support
1e54913

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/init.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/build.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/language_python.go Outdated

kailan added 4 commits August 4, 2026 16:04

Move Python CHANGELOG entry to Unreleased
3bc678f
The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

Drop redundant nil validator in starter kit URL prompt
c97db52
text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Error on missing Python toolchain_constraint
d54cbf2
Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

Merge remote-tracking branch 'origin/main' into posborne/python-langu…
5f12b6f
…age-support # Conflicts: # CHANGELOG.md

kailan removed the DO NOT MERGE YET label Aug 4, 2026

anthony-gomez-fastly approved these changes Aug 4, 2026
View reviewed changes

anthony-gomez-fastly enabled auto-merge (squash) August 4, 2026 15:19

anthony-gomez-fastly merged commit f975ca4 into mainAug 4, 2026
19 of 23 checks passed

anthony-gomez-fastly deleted the posborne/python-language-support branch August 4, 2026 15:25

BrewTestBot mentioned this pull request Aug 4, 2026
fastly 15.5.0 Homebrew/homebrew-core#297065
Merged

kailan mentioned this pull request Aug 7, 2026
[CDTOOL-1707] add Python starter kit to the static config #1877
Merged
4 tasks

posborne mentioned this pull request Aug 12, 2026
Update deps and bump version to 0.1.3 fastly/compute-sdk-python#115
Merged

posborne added 3 commits June 3, 2026 14:11

Add support for the Python programming language
c7b818f
Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Avoid panic when prompt language has empty starter kits
5fc35b2
Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

posborne requested a review from a team as a code owner June 3, 2026 19:25

posborne requested a review from anthony-gomez-fastly June 3, 2026 19:25

posborne added 2 commits June 3, 2026 16:32

Address gosec file permission warnings in metadata unit tests
088b021
Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

Update CHANGELOG.md to note Python language addition
dd0ac32

anthony-gomez-fastly reviewed Jun 4, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

Update CHANGELOG.md
c9baae9
Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne added the DO NOT MERGE YET label Jun 4, 2026

posborne added 2 commits June 5, 2026 13:04

test(compute): add build test scenarios for Python language
ac87f1c
Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

Install uv in CI for tests
f3b8e2c

kpfleming changed the title ~~Add Python Language Support~~CDTOOL-1649: Add Python Language SupportJun 15, 2026

Merge branch 'main' into posborne/python-language-support
1e54913

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/init.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/build.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/language_python.go Outdated

kailan added 4 commits August 4, 2026 16:04

Move Python CHANGELOG entry to Unreleased
3bc678f
The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

Drop redundant nil validator in starter kit URL prompt
c97db52
text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Error on missing Python toolchain_constraint
d54cbf2
Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

Merge remote-tracking branch 'origin/main' into posborne/python-langu…
5f12b6f
…age-support # Conflicts: # CHANGELOG.md

kailan removed the DO NOT MERGE YET label Aug 4, 2026

anthony-gomez-fastly approved these changes Aug 4, 2026
View reviewed changes

anthony-gomez-fastly enabled auto-merge (squash) August 4, 2026 15:19

anthony-gomez-fastly merged commit f975ca4 into mainAug 4, 2026
19 of 23 checks passed

anthony-gomez-fastly deleted the posborne/python-language-support branch August 4, 2026 15:25

BrewTestBot mentioned this pull request Aug 4, 2026
fastly 15.5.0 Homebrew/homebrew-core#297065
Merged

kailan mentioned this pull request Aug 7, 2026
[CDTOOL-1707] add Python starter kit to the static config #1877
Merged
4 tasks

posborne mentioned this pull request Aug 12, 2026
Update deps and bump version to 0.1.3 fastly/compute-sdk-python#115
Merged

posborne added 3 commits June 3, 2026 14:11

Add support for the Python programming language
c7b818f
Add configuration, toolchain parsing, version validation, and build scaffolding for Python projects inside the compute environment. Host Python >= 3.11 and uv are utilized as standard toolchain constraints.

Avoid panic when prompt language has empty starter kits
5fc35b2
Ensure PromptForStarterKit does not index out-of-bounds when there are no configured starter kits for a language. Instead, prompt the user for a template git URL directly, or fail gracefully if non-interactive.

posborne requested a review from a team as a code owner June 3, 2026 19:25

posborne requested a review from anthony-gomez-fastly June 3, 2026 19:25

posborne added 2 commits June 3, 2026 16:32

Address gosec file permission warnings in metadata unit tests
088b021
Use 0600 permissions for mock WASM files and add gosec ignore directives for mock executable creation.

Update CHANGELOG.md to note Python language addition
dd0ac32

anthony-gomez-fastly reviewed Jun 4, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

Update CHANGELOG.md
c9baae9
Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>

posborne added the DO NOT MERGE YET label Jun 4, 2026

posborne added 2 commits June 5, 2026 13:04

test(compute): add build test scenarios for Python language
ac87f1c
Introduce TestBuildPython to build_test.go covering: - Handling missing fastly.toml manifest - Handling of typical build-time failures - Dependency checks - Basic python example

Install uv in CI for tests
f3b8e2c

kpfleming changed the title ~~Add Python Language Support~~CDTOOL-1649: Add Python Language SupportJun 15, 2026

Merge branch 'main' into posborne/python-language-support
1e54913

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadCHANGELOG.md Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/init.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/build.go Outdated

anthony-gomez-fastly reviewed Jul 30, 2026
View reviewed changes

Comment threadpkg/commands/compute/language_python.go Outdated

kailan added 4 commits August 4, 2026 16:04

Move Python CHANGELOG entry to Unreleased
3bc678f
The entry was under the already-released v15.2.0 section. Also aligns the PR link formatting with the surrounding entries.

Drop redundant nil validator in starter kit URL prompt
c97db52
text.Input takes variadic validators, so omitting the argument is the way to skip validation.

Error on missing Python toolchain_constraint
d54cbf2
Silently falling back to a hardcoded ">= 3.11" hid a broken or outdated CLI config and could validate against a constraint we never shipped.

Merge remote-tracking branch 'origin/main' into posborne/python-langu…
5f12b6f
…age-support # Conflicts: # CHANGELOG.md

kailan removed the DO NOT MERGE YET label Aug 4, 2026

anthony-gomez-fastly approved these changes Aug 4, 2026
View reviewed changes

anthony-gomez-fastly enabled auto-merge (squash) August 4, 2026 15:19

anthony-gomez-fastly merged commit f975ca4 into mainAug 4, 2026
19 of 23 checks passed

anthony-gomez-fastly deleted the posborne/python-language-support branch August 4, 2026 15:25

BrewTestBot mentioned this pull request Aug 4, 2026
fastly 15.5.0 Homebrew/homebrew-core#297065
Merged

kailan mentioned this pull request Aug 7, 2026
[CDTOOL-1707] add Python starter kit to the static config #1877
Merged
4 tasks

posborne mentioned this pull request Aug 12, 2026
Update deps and bump version to 0.1.3 fastly/compute-sdk-python#115
Merged

Uh oh!

Conversation

posborne commented Jun 3, 2026

Uh oh!

Uh oh!

anthony-gomez-fastly commented Jun 4, 2026

Uh oh!

posborne commented Jun 4, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kailan commented Aug 4, 2026

Uh oh!

anthony-gomez-fastly left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

posborne commented Jun 3, 2026

Uh oh!

Uh oh!

anthony-gomez-fastly commented Jun 4, 2026

Uh oh!

posborne commented Jun 4, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kailan commented Aug 4, 2026

Uh oh!

anthony-gomez-fastly left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

posborne commented Jun 3, 2026

Uh oh!

Uh oh!

anthony-gomez-fastly commented Jun 4, 2026

Uh oh!

posborne commented Jun 4, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kailan commented Aug 4, 2026

Uh oh!

anthony-gomez-fastly left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!