Repository navigation
CDTOOL-1649: Add Python Language Support - #1811
Conversation
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.
|
is it worth writing any tests in |
Co-authored-by: Anthony Gomez <anthony.gomez@fastly.com>
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
kpfleming
changed the title
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.
|
Review feedback is addressed across four commits (3bc678f, c97db52, d360125, d54cbf2). Verified end-to-end by building the CLI and running Three things worth flagging before this merges: 1. I confirmed this empirically: running The good news is the shapes line up: 2. The embedded 3. |
…age-support # Conflicts: # CHANGELOG.md
anthony-gomez-fastly
left a comment
anthony-gomez-fastly
left a comment
There was a problem hiding this comment.
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>
fastly 15.5.0 Created-by: HarmonybrewBot Commit-by: HarmonybrewBot Merged-by: HarmonybrewBot Description: Created by `brew bump` --- Created with `brew bump-formula-pr`.<details> <summary>release notes</summary> <pre>## [v15.5.0](https://github.com/fastly/cli/releases/tag/v15.5.0) (2026-08-04) ### Bug Fixes: - fix(service-version): support autoclone when staging a service version. ([#1850](fastly/cli#1850)) - fix(logging): the `placement` flag for all loggging commands can now be reset back to `null` by setting it's value to `""` when it was previously set to another value ([#1855](fastly/cli#1855)) - fix(profile): profiles can now be created and updated with service-limited tokens, which cannot access `/current_user` ([#1856](fastly/cli#1856)) ### Enhancements: - feat(compute/init): add support for Python language ([#1811](fastly/cli#1811)) - feat(integrations): Add support for Notification Service Integrations ([#1868](fastly/cli#1868)) ### Dependencies: - build(deps): `golang.org/x/crypto` from 0.53.0 to 0.54.0 ([#1847](fastly/cli#1847)) - build(deps): `github.com/bodgit/sevenzip` from 1.6.4 to 1.6.5 ([#1847](fastly/cli#1847)) - build(deps): `github.com/minio/minlz` from 1.1.1 to 1.2.0 ([#1847](fastly/cli#1847)) - build(deps): `github.com/coreos/go-oidc/v3` from 3.19.0 to 3.20.0 ([#1847](fastly/cli#1847)) - build(deps): `golang.org/x/net` from 0.56.0 to 0.57.0 ([#1847](fastly/cli#1847)) - build(deps): `github.com/fastly/go-fastly` from 16.0.1 to 17.0.0 ([#1855](fastly/cli#1855)) - build(deps): `github.com/mattn/go-isatty` from 0.0.23 to 0.0.24 ([#1857](fastly/cli#1857)) - build(deps): `github.com/nwaples/rardecode/v2` from 2.2.5 to 2.3.0 ([#1857](fastly/cli#1857)) - build(deps): `github.com/mattn/go-runewidth` from 0.0.24 to 0.0.27 ([#1857](fastly/cli#1857)) - build(deps): `github.com/fastly/go-fastly/v17` from 17.0.0 to 17.1.0 ([#1862](https://github.com/fastly/cli/pull/1862))</pre> <p>View the full release notes at <a href="https://github.com/fastly/cli/releases/tag/v15.5.0">https://github.com/fastly/cli/releases/tag/v15.5.0</a>.</p> </details> <hr> See merge request: Harmonybrew/homebrew-core!15863
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-pywhich 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 buildprocess. 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.