Add default Python starter kit and release CI packaging

[posborne]

Having starter kits (just the default for now) available as release artifacts provides a path for integration with the fastly CLI without creating additional repos.

---

For now, this is primarily exploring a concept and as a holding place for discussion of this approach as well as what we might want in the default SDK. I tested this locally as follows with my fork of the CLI and was able to initalize a project successfully (against a local http server).

I intentially do not include version numbers in the artifact names in order to support use of "latest" in the path as that is likely desired if to be directly integrated into the CLI. Depending on how we like the pattern, dynamic template discovery seems feasible as well.

CLI output from local test run

$ ../cli/fastly compute init --language python --from 'http://localhost:8000/starter-kit-python-default.zip'
Creating a new Compute project (using --from to locate package template).
Press ^C at any time to quit.
The current directory isn't empty. Are you sure you want to initialize a Compute project in /Users/paul.osborne/Projects/Fastly/new-python? [y/N] y
✓ Validating directory permissions
Name: [new-python] Description: Author (email): [...] ✓ Fetching package template
✓ Reading fastly.toml
✓ Setting package name in manifest to "new-python"
✓ Setting description in manifest
✓ Setting authors in manifest to 'osbpau@gmail.com'
✓ Setting language in manifest to 'python'
✓ Saving manifest changes
✓ Initializing package
Initialized package new-python to:
.../new-python
To publish the package (build and deploy), run:
fastly compute publish
To learn about deploying Compute projects using third-party orchestration tools, visit:
https://www.fastly.com/documentation/guides/integrations/orchestration
SUCCESS: Initialized package new-python

[kpfleming]

As I noted in the internal discussion I'm not super excited about publishing starter kits differently than we do today, but it's not a dead-end. This would need CI workflows for building and testing the starter kit against a published copy of the SDK, and will need Dependabot setup to keep it updated as there are new releases of the SDK and its other dependencies. Ideally the build-and-test workflow would be similar to this one and live in that repository.

[posborne]

Closing in favor of the traditional starter-kit approach out of tree.

[posborne]

Having starter kits (just the default for now) available as release artifacts provides a path for integration with the fastly CLI without creating additional repos.

---

For now, this is primarily exploring a concept and as a holding place for discussion of this approach as well as what we might want in the default SDK. I tested this locally as follows with my fork of the CLI and was able to initalize a project successfully (against a local http server).

I intentially do not include version numbers in the artifact names in order to support use of "latest" in the path as that is likely desired if to be directly integrated into the CLI. Depending on how we like the pattern, dynamic template discovery seems feasible as well.

CLI output from local test run

$ ../cli/fastly compute init --language python --from 'http://localhost:8000/starter-kit-python-default.zip'
Creating a new Compute project (using --from to locate package template).
Press ^C at any time to quit.
The current directory isn't empty. Are you sure you want to initialize a Compute project in /Users/paul.osborne/Projects/Fastly/new-python? [y/N] y
✓ Validating directory permissions
Name: [new-python] Description: Author (email): [...] ✓ Fetching package template
✓ Reading fastly.toml
✓ Setting package name in manifest to "new-python"
✓ Setting description in manifest
✓ Setting authors in manifest to 'osbpau@gmail.com'
✓ Setting language in manifest to 'python'
✓ Saving manifest changes
✓ Initializing package
Initialized package new-python to:
.../new-python
To publish the package (build and deploy), run:
fastly compute publish
To learn about deploying Compute projects using third-party orchestration tools, visit:
https://www.fastly.com/documentation/guides/integrations/orchestration
SUCCESS: Initialized package new-python

[kpfleming]

As I noted in the internal discussion I'm not super excited about publishing starter kits differently than we do today, but it's not a dead-end. This would need CI workflows for building and testing the starter kit against a published copy of the SDK, and will need Dependabot setup to keep it updated as there are new releases of the SDK and its other dependencies. Ideally the build-and-test workflow would be similar to this one and live in that repository.

[posborne]

Closing in favor of the traditional starter-kit approach out of tree.

[posborne]

Having starter kits (just the default for now) available as release artifacts provides a path for integration with the fastly CLI without creating additional repos.

---

For now, this is primarily exploring a concept and as a holding place for discussion of this approach as well as what we might want in the default SDK. I tested this locally as follows with my fork of the CLI and was able to initalize a project successfully (against a local http server).

I intentially do not include version numbers in the artifact names in order to support use of "latest" in the path as that is likely desired if to be directly integrated into the CLI. Depending on how we like the pattern, dynamic template discovery seems feasible as well.

CLI output from local test run

$ ../cli/fastly compute init --language python --from 'http://localhost:8000/starter-kit-python-default.zip'
Creating a new Compute project (using --from to locate package template).
Press ^C at any time to quit.
The current directory isn't empty. Are you sure you want to initialize a Compute project in /Users/paul.osborne/Projects/Fastly/new-python? [y/N] y
✓ Validating directory permissions
Name: [new-python] Description: Author (email): [...] ✓ Fetching package template
✓ Reading fastly.toml
✓ Setting package name in manifest to "new-python"
✓ Setting description in manifest
✓ Setting authors in manifest to 'osbpau@gmail.com'
✓ Setting language in manifest to 'python'
✓ Saving manifest changes
✓ Initializing package
Initialized package new-python to:
.../new-python
To publish the package (build and deploy), run:
fastly compute publish
To learn about deploying Compute projects using third-party orchestration tools, visit:
https://www.fastly.com/documentation/guides/integrations/orchestration
SUCCESS: Initialized package new-python

[kpfleming]

As I noted in the internal discussion I'm not super excited about publishing starter kits differently than we do today, but it's not a dead-end. This would need CI workflows for building and testing the starter kit against a published copy of the SDK, and will need Dependabot setup to keep it updated as there are new releases of the SDK and its other dependencies. Ideally the build-and-test workflow would be similar to this one and live in that repository.

[posborne]

Closing in favor of the traditional starter-kit approach out of tree.

[posborne]

Having starter kits (just the default for now) available as release artifacts provides a path for integration with the fastly CLI without creating additional repos.

---

For now, this is primarily exploring a concept and as a holding place for discussion of this approach as well as what we might want in the default SDK. I tested this locally as follows with my fork of the CLI and was able to initalize a project successfully (against a local http server).

I intentially do not include version numbers in the artifact names in order to support use of "latest" in the path as that is likely desired if to be directly integrated into the CLI. Depending on how we like the pattern, dynamic template discovery seems feasible as well.

CLI output from local test run

$ ../cli/fastly compute init --language python --from 'http://localhost:8000/starter-kit-python-default.zip'
Creating a new Compute project (using --from to locate package template).
Press ^C at any time to quit.
The current directory isn't empty. Are you sure you want to initialize a Compute project in /Users/paul.osborne/Projects/Fastly/new-python? [y/N] y
✓ Validating directory permissions
Name: [new-python] Description: Author (email): [...] ✓ Fetching package template
✓ Reading fastly.toml
✓ Setting package name in manifest to "new-python"
✓ Setting description in manifest
✓ Setting authors in manifest to 'osbpau@gmail.com'
✓ Setting language in manifest to 'python'
✓ Saving manifest changes
✓ Initializing package
Initialized package new-python to:
.../new-python
To publish the package (build and deploy), run:
fastly compute publish
To learn about deploying Compute projects using third-party orchestration tools, visit:
https://www.fastly.com/documentation/guides/integrations/orchestration
SUCCESS: Initialized package new-python

[kpfleming]

As I noted in the internal discussion I'm not super excited about publishing starter kits differently than we do today, but it's not a dead-end. This would need CI workflows for building and testing the starter kit against a published copy of the SDK, and will need Dependabot setup to keep it updated as there are new releases of the SDK and its other dependencies. Ideally the build-and-test workflow would be similar to this one and live in that repository.

[posborne]

Closing in favor of the traditional starter-kit approach out of tree.

[posborne]

Having starter kits (just the default for now) available as release artifacts provides a path for integration with the fastly CLI without creating additional repos.

---

For now, this is primarily exploring a concept and as a holding place for discussion of this approach as well as what we might want in the default SDK. I tested this locally as follows with my fork of the CLI and was able to initalize a project successfully (against a local http server).

I intentially do not include version numbers in the artifact names in order to support use of "latest" in the path as that is likely desired if to be directly integrated into the CLI. Depending on how we like the pattern, dynamic template discovery seems feasible as well.

CLI output from local test run

$ ../cli/fastly compute init --language python --from 'http://localhost:8000/starter-kit-python-default.zip'
Creating a new Compute project (using --from to locate package template).
Press ^C at any time to quit.
The current directory isn't empty. Are you sure you want to initialize a Compute project in /Users/paul.osborne/Projects/Fastly/new-python? [y/N] y
✓ Validating directory permissions
Name: [new-python] Description: Author (email): [...] ✓ Fetching package template
✓ Reading fastly.toml
✓ Setting package name in manifest to "new-python"
✓ Setting description in manifest
✓ Setting authors in manifest to 'osbpau@gmail.com'
✓ Setting language in manifest to 'python'
✓ Saving manifest changes
✓ Initializing package
Initialized package new-python to:
.../new-python
To publish the package (build and deploy), run:
fastly compute publish
To learn about deploying Compute projects using third-party orchestration tools, visit:
https://www.fastly.com/documentation/guides/integrations/orchestration
SUCCESS: Initialized package new-python

[kpfleming]

As I noted in the internal discussion I'm not super excited about publishing starter kits differently than we do today, but it's not a dead-end. This would need CI workflows for building and testing the starter kit against a published copy of the SDK, and will need Dependabot setup to keep it updated as there are new releases of the SDK and its other dependencies. Ideally the build-and-test workflow would be similar to this one and live in that repository.

[posborne]

Closing in favor of the traditional starter-kit approach out of tree.

[posborne]

Having starter kits (just the default for now) available as release artifacts provides a path for integration with the fastly CLI without creating additional repos.

---

For now, this is primarily exploring a concept and as a holding place for discussion of this approach as well as what we might want in the default SDK. I tested this locally as follows with my fork of the CLI and was able to initalize a project successfully (against a local http server).

I intentially do not include version numbers in the artifact names in order to support use of "latest" in the path as that is likely desired if to be directly integrated into the CLI. Depending on how we like the pattern, dynamic template discovery seems feasible as well.

CLI output from local test run

$ ../cli/fastly compute init --language python --from 'http://localhost:8000/starter-kit-python-default.zip'
Creating a new Compute project (using --from to locate package template).
Press ^C at any time to quit.
The current directory isn't empty. Are you sure you want to initialize a Compute project in /Users/paul.osborne/Projects/Fastly/new-python? [y/N] y
✓ Validating directory permissions
Name: [new-python] Description: Author (email): [...] ✓ Fetching package template
✓ Reading fastly.toml
✓ Setting package name in manifest to "new-python"
✓ Setting description in manifest
✓ Setting authors in manifest to 'osbpau@gmail.com'
✓ Setting language in manifest to 'python'
✓ Saving manifest changes
✓ Initializing package
Initialized package new-python to:
.../new-python
To publish the package (build and deploy), run:
fastly compute publish
To learn about deploying Compute projects using third-party orchestration tools, visit:
https://www.fastly.com/documentation/guides/integrations/orchestration
SUCCESS: Initialized package new-python

[kpfleming]

As I noted in the internal discussion I'm not super excited about publishing starter kits differently than we do today, but it's not a dead-end. This would need CI workflows for building and testing the starter kit against a published copy of the SDK, and will need Dependabot setup to keep it updated as there are new releases of the SDK and its other dependencies. Ideally the build-and-test workflow would be similar to this one and live in that repository.

[posborne]

Closing in favor of the traditional starter-kit approach out of tree.

[posborne]

Having starter kits (just the default for now) available as release artifacts provides a path for integration with the fastly CLI without creating additional repos.

---

For now, this is primarily exploring a concept and as a holding place for discussion of this approach as well as what we might want in the default SDK. I tested this locally as follows with my fork of the CLI and was able to initalize a project successfully (against a local http server).

I intentially do not include version numbers in the artifact names in order to support use of "latest" in the path as that is likely desired if to be directly integrated into the CLI. Depending on how we like the pattern, dynamic template discovery seems feasible as well.

CLI output from local test run

$ ../cli/fastly compute init --language python --from 'http://localhost:8000/starter-kit-python-default.zip'
Creating a new Compute project (using --from to locate package template).
Press ^C at any time to quit.
The current directory isn't empty. Are you sure you want to initialize a Compute project in /Users/paul.osborne/Projects/Fastly/new-python? [y/N] y
✓ Validating directory permissions
Name: [new-python] Description: Author (email): [...] ✓ Fetching package template
✓ Reading fastly.toml
✓ Setting package name in manifest to "new-python"
✓ Setting description in manifest
✓ Setting authors in manifest to 'osbpau@gmail.com'
✓ Setting language in manifest to 'python'
✓ Saving manifest changes
✓ Initializing package
Initialized package new-python to:
.../new-python
To publish the package (build and deploy), run:
fastly compute publish
To learn about deploying Compute projects using third-party orchestration tools, visit:
https://www.fastly.com/documentation/guides/integrations/orchestration
SUCCESS: Initialized package new-python

[kpfleming]

As I noted in the internal discussion I'm not super excited about publishing starter kits differently than we do today, but it's not a dead-end. This would need CI workflows for building and testing the starter kit against a published copy of the SDK, and will need Dependabot setup to keep it updated as there are new releases of the SDK and its other dependencies. Ideally the build-and-test workflow would be similar to this one and live in that repository.

[posborne]

Closing in favor of the traditional starter-kit approach out of tree.

[posborne]

Having starter kits (just the default for now) available as release artifacts provides a path for integration with the fastly CLI without creating additional repos.

---

For now, this is primarily exploring a concept and as a holding place for discussion of this approach as well as what we might want in the default SDK. I tested this locally as follows with my fork of the CLI and was able to initalize a project successfully (against a local http server).

I intentially do not include version numbers in the artifact names in order to support use of "latest" in the path as that is likely desired if to be directly integrated into the CLI. Depending on how we like the pattern, dynamic template discovery seems feasible as well.

CLI output from local test run

$ ../cli/fastly compute init --language python --from 'http://localhost:8000/starter-kit-python-default.zip'
Creating a new Compute project (using --from to locate package template).
Press ^C at any time to quit.
The current directory isn't empty. Are you sure you want to initialize a Compute project in /Users/paul.osborne/Projects/Fastly/new-python? [y/N] y
✓ Validating directory permissions
Name: [new-python] Description: Author (email): [...] ✓ Fetching package template
✓ Reading fastly.toml
✓ Setting package name in manifest to "new-python"
✓ Setting description in manifest
✓ Setting authors in manifest to 'osbpau@gmail.com'
✓ Setting language in manifest to 'python'
✓ Saving manifest changes
✓ Initializing package
Initialized package new-python to:
.../new-python
To publish the package (build and deploy), run:
fastly compute publish
To learn about deploying Compute projects using third-party orchestration tools, visit:
https://www.fastly.com/documentation/guides/integrations/orchestration
SUCCESS: Initialized package new-python

[kpfleming]

As I noted in the internal discussion I'm not super excited about publishing starter kits differently than we do today, but it's not a dead-end. This would need CI workflows for building and testing the starter kit against a published copy of the SDK, and will need Dependabot setup to keep it updated as there are new releases of the SDK and its other dependencies. Ideally the build-and-test workflow would be similar to this one and live in that repository.

[posborne]

Closing in favor of the traditional starter-kit approach out of tree.