-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revise Django / Wagtail project template approach #371
Comments
Given a list of dependencies, npm can install them and create a package.json and package-lock.json pinning their versions, e.g., npm i react react-dom react-leaflet |
Started this here: https://github.com/datamade/cookiecutter-django-app |
@hancush let me know whenever this django app is ready to go and i can start automatically opening prs for dependency updates on this instead of the how-to repo! no rush of course |
@xmedr That shouldn't be necessary, actually! The new cookiecutter includes a list of core JavaScript dependencies (negotiable what makes the list). After the new project is generated, Cookiecutter will It also pins the latest version of Django or Wagtail, depending on which framework is installed. If we want a default list of Python dependencies, e.g., for testing, we'll take a similar approach as described above for JavaScript deps. |
looks like a real improvement to what we are doing now! this approach to dependencies also won't make any guarantees that the code the cookiecutter outputs is in a non-broken state. that would be be mitigated by having a nightly scheduled job to test test if the code still works with the latest dependencies and a commitment to adjusting the code when it fails. |
Background
Spin off from #318, #278
We have templates for Django and Wagtail projects, but the scaffolding is largely the same, which means we have two places to update code and configs as we refine our stack. We don't always do this, e.g., the Wagtail template is still using Django Compressor instead of WebPack. Moreover, boilerplate code means that our templates must be updated to account for breaking changes when Django / Wagtail have major version releases, and we have not found an easy way to keep other dependencies up to date. Finally, using our cookiecutters isn't very ergonomic, because you have to clone and update this repository, and darn it, I can never find them on first try, even though I'm the one that originally put them in the
docker/templates/
directory.Proposal
I propose three things:
startproject
command that comes out of the box with Django and is extended by Wagtailpost_gen_project_hook
that:startproject
Deliverables
I will rehome the vanilla JavaScript cookiecutter to its own repositories. I will then create a combined Django / Wagtail cookiecutter following the proposal above. All other cookiecutters will be retired.
Timeline
I expect this to take a day or two.
The text was updated successfully, but these errors were encountered: