[CDTOOL-1707] add Python starter kit to the static config

[kailan]

Change summary

Fixes 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, 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:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• 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

[anthony-gomez-fastly]

LGTM!

[kailan]

Change summary

Fixes 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, 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:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• 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

[anthony-gomez-fastly]

LGTM!

[kailan]

Change summary

Fixes 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, 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:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• 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

[anthony-gomez-fastly]

LGTM!

[kailan]

Change summary

Fixes 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, 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:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• 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

[anthony-gomez-fastly]

LGTM!

[kailan]

Change summary

Fixes 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, 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:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• 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

[anthony-gomez-fastly]

LGTM!

[kailan]

Change summary

Fixes 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, 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:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• 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

[anthony-gomez-fastly]

LGTM!

[kailan]

Change summary

Fixes 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, 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:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• 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

[anthony-gomez-fastly]

LGTM!

[kailan]

Change summary

Fixes 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, 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:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• 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

[anthony-gomez-fastly]

LGTM!