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!
3 participants
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.