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
|
|
||
| - feat(dns): add support for DNS Zones and TSIG Keys ([#1809](https://github.com/fastly/cli/pull/1809)) | ||
| - fix(compute/init): Add starter kits for C++ language [#1807](https://github.com/fastly/cli/pull/1807) | ||
| - feat(compute/init): add support for Python language [#1811](https://github.com/fastly/cli/pull/1811) |
There was a problem hiding this comment.
Going to need to shift this to the right spot
| return "", "", "", errors.New("no default starter kits configured for this language; please specify a template using the --from flag") | ||
| } | ||
| text.Info(out, "\nNo default starter kits are currently configured for this language.") | ||
| option, err = text.Input(out, "Please paste a template git URL: ", in, nil) |
There was a problem hiding this comment.
i think you can not pass nil here
| // remaining fields it is responsible for. | ||
| dc := DataCollection{} | ||
| if existing := c.readExistingFastlyData(wasmtools); existing != nil { | ||
| dc = *existing |
There was a problem hiding this comment.
instead of overwriting the whole dc, do we only want to overwrite package_info?
There was a problem hiding this comment.
also is this used for all languages or just python?
| func (p *Python) checkPythonVersion() error { | ||
| requiredConstraint := p.config.ToolchainConstraint | ||
| if requiredConstraint == "" { | ||
| requiredConstraint = ">= 3.11" |
There was a problem hiding this comment.
can we error instead of setting this?
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.