Closed lucasmelin closed 2 years ago
The target for this PR is currently the cookiecutter
branch, but @marceloKatayama and @slougheed do you think we should go all-in on the cookiecutter implementation and replace main
with the cookiecutter-ified version and delete https://github.com/bocdaz/template-python-fastapi at the same time?
The target for this PR is currently the
cookiecutter
branch, but @marceloKatayama and @slougheed do you think we should go all-in on the cookiecutter implementation and replacemain
with the cookiecutter-ified version and delete https://github.com/bocdaz/template-python-fastapi at the same time?
I would like to limit the number of template repositories and/or branches that we have to maintain so yes, I'm in for going all in on a cookiecutter implementation. To take it one step further and drop the requirement that people have cookiecutter installed on their own system, I found this: https://simonwillison.net/2021/Aug/28/dynamic-github-repository-templates/ which will use a github actions to run cookiecutter and rewrite a new repo after it is created. (If I've read the writeup correctly)
That GitHub Action is a great idea, I was wondering if that was possible. Using the GitHub API like that is a neat trick.
I would like to limit the number of template repositories and/or branches that we have to maintain so yes, I'm in for going all in on a cookiecutter implementation. To take it one step further and drop the requirement that people have cookiecutter installed on their own system, I found this: https://simonwillison.net/2021/Aug/28/dynamic-github-repository-templates/ which will use a github actions to run cookiecutter and rewrite a new repo after it is created. (If I've read the writeup correctly)
As a rebuttal to my own argument, are we moving to a complex "monolithic-template" rather than a series of small, easy to manage templates? We need a "master-template" where we can add common files that then spread to all the sub-templates. ... I might be getting carried away here.
Looking at Simon Willison's templates, it looks like he has a separate template for a regular python app and a click app, which is probably due in part to the fact that if we adopt the GitHub Actions approach, the template wouldn't know which "flavour" of the template we want to create.
Looking at Simon Willison's templates, it looks like he has a separate template for a regular python app and a click app, which is probably due in part to the fact that if we adopt the GitHub Actions approach, the template wouldn't know which "flavour" of the template we want to create.
Seems like those are actually empty shell repositories that handle the values sent to the GitHub API. So theoretically I guess the template repos could call out to either one monolithic cookiecutter repo, or to individual purpose-built repos.
After going back and forth on this in my mind, I think I'm in favour of treating this as the "monolithic python template" for now, especially as things fluctuate a bit more with regards to development tooling - updating it once here will be easier as less prone to configuration drift while we figure out the best approach that works with our environment.
If we feel like we're accumulating too much conditional logic that makes it hard to reason about this template, then we can revisit the idea of small sub-templates then, but for the time-being, I think consolidation provides benefits.
Combine FastAPI template into this project. Files are conditionally added/modified based mainly on the chosen
project_type
which for now is either aFastAPI application
or aPython program
.Closes DEV-208