Use a human-readable name in fastly.toml by kailan · Pull Request #6 · fastly/compute-starter-kit-python-default

kailan · 2026-08-07T14:15:44Z

Change summary

Related to CDTOOL-1707 / fastly/cli#1877.

The Fastly CLI builds its starter kit list at release build time by copying the name and description fields out of each kit's fastly.toml (scripts/config.sh), so name is what users see at the fastly compute init starter kit prompt.

Every other starter kit uses a human-readable label there — "Default starter for Go", "Default starter for Rust", "Default starter kit for C++" — but this kit used the Python distribution name, so once the CLI picks the kit up it would render as:

Starter kit:
[1] fastly-compute-python-app
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

After this change:

Starter kit:
[1] Default starter for Python
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

(verified locally against a CLI build with the field patched into its static config)

The [project] name in pyproject.toml is deliberately left alone — it has to remain a valid Python distribution name and is unrelated to what the CLI displays. fastly.toml's name is the Fastly package name, which compute init overwrites with the user's project name anyway.

This should merge before fastly/cli#1877 is released, since the CLI regenerates its config from main on each build.

🤖 Generated with Claude Code

The Fastly CLI builds its list of starter kits by copying the `name` and `description` fields out of each kit's fastly.toml, so this field is what users see at the `fastly compute init` starter kit prompt. Every other starter kit uses a human-readable label there ("Default starter for Go", "Default starter kit for C++"), whereas this kit used the Python distribution name and rendered as: [1] fastly-compute-python-app The Python distribution name in pyproject.toml is unchanged; that field has to stay a valid package name and is unrelated to what the CLI shows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kailan · 2026-08-07T14:23:29Z

CI here is red on a pre-existing ruff check failure in main.py (I001, un-sorted imports) that is unrelated to this one-line fastly.toml change — the Test workflow has failed on every run since this repo was created.

Split out into #7. Once that merges I'll rebase this branch, which should get both green.

### 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>

kailan · 2026-08-07T14:15:44Z

Change summary

Related to CDTOOL-1707 / fastly/cli#1877.

The Fastly CLI builds its starter kit list at release build time by copying the name and description fields out of each kit's fastly.toml (scripts/config.sh), so name is what users see at the fastly compute init starter kit prompt.

Every other starter kit uses a human-readable label there — "Default starter for Go", "Default starter for Rust", "Default starter kit for C++" — but this kit used the Python distribution name, so once the CLI picks the kit up it would render as:

Starter kit:
[1] fastly-compute-python-app
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

After this change:

Starter kit:
[1] Default starter for Python
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

(verified locally against a CLI build with the field patched into its static config)

The [project] name in pyproject.toml is deliberately left alone — it has to remain a valid Python distribution name and is unrelated to what the CLI displays. fastly.toml's name is the Fastly package name, which compute init overwrites with the user's project name anyway.

This should merge before fastly/cli#1877 is released, since the CLI regenerates its config from main on each build.

🤖 Generated with Claude Code

The Fastly CLI builds its list of starter kits by copying the `name` and `description` fields out of each kit's fastly.toml, so this field is what users see at the `fastly compute init` starter kit prompt. Every other starter kit uses a human-readable label there ("Default starter for Go", "Default starter kit for C++"), whereas this kit used the Python distribution name and rendered as: [1] fastly-compute-python-app The Python distribution name in pyproject.toml is unchanged; that field has to stay a valid package name and is unrelated to what the CLI shows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kailan · 2026-08-07T14:23:29Z

CI here is red on a pre-existing ruff check failure in main.py (I001, un-sorted imports) that is unrelated to this one-line fastly.toml change — the Test workflow has failed on every run since this repo was created.

Split out into #7. Once that merges I'll rebase this branch, which should get both green.

### 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>

kailan · 2026-08-07T14:15:44Z

Change summary

Related to CDTOOL-1707 / fastly/cli#1877.

The Fastly CLI builds its starter kit list at release build time by copying the name and description fields out of each kit's fastly.toml (scripts/config.sh), so name is what users see at the fastly compute init starter kit prompt.

Every other starter kit uses a human-readable label there — "Default starter for Go", "Default starter for Rust", "Default starter kit for C++" — but this kit used the Python distribution name, so once the CLI picks the kit up it would render as:

Starter kit:
[1] fastly-compute-python-app
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

After this change:

Starter kit:
[1] Default starter for Python
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

(verified locally against a CLI build with the field patched into its static config)

The [project] name in pyproject.toml is deliberately left alone — it has to remain a valid Python distribution name and is unrelated to what the CLI displays. fastly.toml's name is the Fastly package name, which compute init overwrites with the user's project name anyway.

This should merge before fastly/cli#1877 is released, since the CLI regenerates its config from main on each build.

🤖 Generated with Claude Code

The Fastly CLI builds its list of starter kits by copying the `name` and `description` fields out of each kit's fastly.toml, so this field is what users see at the `fastly compute init` starter kit prompt. Every other starter kit uses a human-readable label there ("Default starter for Go", "Default starter kit for C++"), whereas this kit used the Python distribution name and rendered as: [1] fastly-compute-python-app The Python distribution name in pyproject.toml is unchanged; that field has to stay a valid package name and is unrelated to what the CLI shows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kailan · 2026-08-07T14:23:29Z

CI here is red on a pre-existing ruff check failure in main.py (I001, un-sorted imports) that is unrelated to this one-line fastly.toml change — the Test workflow has failed on every run since this repo was created.

Split out into #7. Once that merges I'll rebase this branch, which should get both green.

### 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>

kailan · 2026-08-07T14:15:44Z

Change summary

Related to CDTOOL-1707 / fastly/cli#1877.

The Fastly CLI builds its starter kit list at release build time by copying the name and description fields out of each kit's fastly.toml (scripts/config.sh), so name is what users see at the fastly compute init starter kit prompt.

Every other starter kit uses a human-readable label there — "Default starter for Go", "Default starter for Rust", "Default starter kit for C++" — but this kit used the Python distribution name, so once the CLI picks the kit up it would render as:

Starter kit:
[1] fastly-compute-python-app
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

After this change:

Starter kit:
[1] Default starter for Python
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

(verified locally against a CLI build with the field patched into its static config)

The [project] name in pyproject.toml is deliberately left alone — it has to remain a valid Python distribution name and is unrelated to what the CLI displays. fastly.toml's name is the Fastly package name, which compute init overwrites with the user's project name anyway.

This should merge before fastly/cli#1877 is released, since the CLI regenerates its config from main on each build.

🤖 Generated with Claude Code

The Fastly CLI builds its list of starter kits by copying the `name` and `description` fields out of each kit's fastly.toml, so this field is what users see at the `fastly compute init` starter kit prompt. Every other starter kit uses a human-readable label there ("Default starter for Go", "Default starter kit for C++"), whereas this kit used the Python distribution name and rendered as: [1] fastly-compute-python-app The Python distribution name in pyproject.toml is unchanged; that field has to stay a valid package name and is unrelated to what the CLI shows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kailan · 2026-08-07T14:23:29Z

CI here is red on a pre-existing ruff check failure in main.py (I001, un-sorted imports) that is unrelated to this one-line fastly.toml change — the Test workflow has failed on every run since this repo was created.

Split out into #7. Once that merges I'll rebase this branch, which should get both green.

### 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>

kailan · 2026-08-07T14:15:44Z

Change summary

Related to CDTOOL-1707 / fastly/cli#1877.

The Fastly CLI builds its starter kit list at release build time by copying the name and description fields out of each kit's fastly.toml (scripts/config.sh), so name is what users see at the fastly compute init starter kit prompt.

Every other starter kit uses a human-readable label there — "Default starter for Go", "Default starter for Rust", "Default starter kit for C++" — but this kit used the Python distribution name, so once the CLI picks the kit up it would render as:

Starter kit:
[1] fastly-compute-python-app
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

After this change:

Starter kit:
[1] Default starter for Python
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

(verified locally against a CLI build with the field patched into its static config)

The [project] name in pyproject.toml is deliberately left alone — it has to remain a valid Python distribution name and is unrelated to what the CLI displays. fastly.toml's name is the Fastly package name, which compute init overwrites with the user's project name anyway.

This should merge before fastly/cli#1877 is released, since the CLI regenerates its config from main on each build.

🤖 Generated with Claude Code

The Fastly CLI builds its list of starter kits by copying the `name` and `description` fields out of each kit's fastly.toml, so this field is what users see at the `fastly compute init` starter kit prompt. Every other starter kit uses a human-readable label there ("Default starter for Go", "Default starter kit for C++"), whereas this kit used the Python distribution name and rendered as: [1] fastly-compute-python-app The Python distribution name in pyproject.toml is unchanged; that field has to stay a valid package name and is unrelated to what the CLI shows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kailan · 2026-08-07T14:23:29Z

CI here is red on a pre-existing ruff check failure in main.py (I001, un-sorted imports) that is unrelated to this one-line fastly.toml change — the Test workflow has failed on every run since this repo was created.

Split out into #7. Once that merges I'll rebase this branch, which should get both green.

### 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>

kailan · 2026-08-07T14:15:44Z

Change summary

Related to CDTOOL-1707 / fastly/cli#1877.

The Fastly CLI builds its starter kit list at release build time by copying the name and description fields out of each kit's fastly.toml (scripts/config.sh), so name is what users see at the fastly compute init starter kit prompt.

Every other starter kit uses a human-readable label there — "Default starter for Go", "Default starter for Rust", "Default starter kit for C++" — but this kit used the Python distribution name, so once the CLI picks the kit up it would render as:

Starter kit:
[1] fastly-compute-python-app
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

After this change:

Starter kit:
[1] Default starter for Python
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

(verified locally against a CLI build with the field patched into its static config)

The [project] name in pyproject.toml is deliberately left alone — it has to remain a valid Python distribution name and is unrelated to what the CLI displays. fastly.toml's name is the Fastly package name, which compute init overwrites with the user's project name anyway.

This should merge before fastly/cli#1877 is released, since the CLI regenerates its config from main on each build.

🤖 Generated with Claude Code

The Fastly CLI builds its list of starter kits by copying the `name` and `description` fields out of each kit's fastly.toml, so this field is what users see at the `fastly compute init` starter kit prompt. Every other starter kit uses a human-readable label there ("Default starter for Go", "Default starter kit for C++"), whereas this kit used the Python distribution name and rendered as: [1] fastly-compute-python-app The Python distribution name in pyproject.toml is unchanged; that field has to stay a valid package name and is unrelated to what the CLI shows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kailan · 2026-08-07T14:23:29Z

CI here is red on a pre-existing ruff check failure in main.py (I001, un-sorted imports) that is unrelated to this one-line fastly.toml change — the Test workflow has failed on every run since this repo was created.

Split out into #7. Once that merges I'll rebase this branch, which should get both green.

### 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>

kailan · 2026-08-07T14:15:44Z

Change summary

Related to CDTOOL-1707 / fastly/cli#1877.

The Fastly CLI builds its starter kit list at release build time by copying the name and description fields out of each kit's fastly.toml (scripts/config.sh), so name is what users see at the fastly compute init starter kit prompt.

Every other starter kit uses a human-readable label there — "Default starter for Go", "Default starter for Rust", "Default starter kit for C++" — but this kit used the Python distribution name, so once the CLI picks the kit up it would render as:

Starter kit:
[1] fastly-compute-python-app
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

After this change:

Starter kit:
[1] Default starter for Python
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

(verified locally against a CLI build with the field patched into its static config)

The [project] name in pyproject.toml is deliberately left alone — it has to remain a valid Python distribution name and is unrelated to what the CLI displays. fastly.toml's name is the Fastly package name, which compute init overwrites with the user's project name anyway.

This should merge before fastly/cli#1877 is released, since the CLI regenerates its config from main on each build.

🤖 Generated with Claude Code

The Fastly CLI builds its list of starter kits by copying the `name` and `description` fields out of each kit's fastly.toml, so this field is what users see at the `fastly compute init` starter kit prompt. Every other starter kit uses a human-readable label there ("Default starter for Go", "Default starter kit for C++"), whereas this kit used the Python distribution name and rendered as: [1] fastly-compute-python-app The Python distribution name in pyproject.toml is unchanged; that field has to stay a valid package name and is unrelated to what the CLI shows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kailan · 2026-08-07T14:23:29Z

CI here is red on a pre-existing ruff check failure in main.py (I001, un-sorted imports) that is unrelated to this one-line fastly.toml change — the Test workflow has failed on every run since this repo was created.

Split out into #7. Once that merges I'll rebase this branch, which should get both green.

### 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>

kailan · 2026-08-07T14:15:44Z

Change summary

Related to CDTOOL-1707 / fastly/cli#1877.

The Fastly CLI builds its starter kit list at release build time by copying the name and description fields out of each kit's fastly.toml (scripts/config.sh), so name is what users see at the fastly compute init starter kit prompt.

Every other starter kit uses a human-readable label there — "Default starter for Go", "Default starter for Rust", "Default starter kit for C++" — but this kit used the Python distribution name, so once the CLI picks the kit up it would render as:

Starter kit:
[1] fastly-compute-python-app
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

After this change:

Starter kit:
[1] Default starter for Python
A basic starter kit that demonstrates routing and simple responses in Python.
https://github.com/fastly/compute-starter-kit-python-default

(verified locally against a CLI build with the field patched into its static config)

The [project] name in pyproject.toml is deliberately left alone — it has to remain a valid Python distribution name and is unrelated to what the CLI displays. fastly.toml's name is the Fastly package name, which compute init overwrites with the user's project name anyway.

This should merge before fastly/cli#1877 is released, since the CLI regenerates its config from main on each build.

🤖 Generated with Claude Code

The Fastly CLI builds its list of starter kits by copying the `name` and `description` fields out of each kit's fastly.toml, so this field is what users see at the `fastly compute init` starter kit prompt. Every other starter kit uses a human-readable label there ("Default starter for Go", "Default starter kit for C++"), whereas this kit used the Python distribution name and rendered as: [1] fastly-compute-python-app The Python distribution name in pyproject.toml is unchanged; that field has to stay a valid package name and is unrelated to what the CLI shows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kailan · 2026-08-07T14:23:29Z

CI here is red on a pre-existing ruff check failure in main.py (I001, un-sorted imports) that is unrelated to this one-line fastly.toml change — the Test workflow has failed on every run since this repo was created.

Split out into #7. Once that merges I'll rebase this branch, which should get both green.

### 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>