Make cookiecutter-django into a template repo #3463
Replies: 9 comments
-
|
@Andrew-Chen-Wang What do you mean with "template repo"? I partially understood the idea, but I don't know if the "template repo" is a GitHub feature that I don't know about ... Anyway, I add a -1 vote for anything that adds more workload to maintainers, especially when it comes to giving free support to companies that make money using open source, but in no way give back for these projects. |
Beta Was this translation helpful? Give feedback.
-
|
Ah a template repository like https://github.com/SimpleJWT/drf-SimpleJWT-React and look at the top left where it says Generated from. There is no additional workload for the maintainers. A GitHub Action cron job that checks for any updates in pydanny/cookiecutter-django. If there are any, update the current repository with pydanny/cookiecutter-django's new changes. The point is you include your normal deployment scripts inside your private cookiecutter-django. The action updates something like requirements/local.txt or Dockerfiles with pydanny/cookiecutter-django's new commits.
Unless you mean answering their questions but not committing it to pydanny/cookiecutter-django, I think it's wrong to say proprietary companies need to give back to open source projects. I think you mean adding a single feature for one company? But then again, a feature added to an open source repository is a feature added for all. |
Beta Was this translation helpful? Give feedback.
-
|
Also @luzfcb. I think I've seen enough of this comment (in no disrespect); we're all volunteers:
browniebroke is busy, for sure, but even in this repository, there are plenty of people volunteering to consistently update the code because we all use the same tool. For example, I recently updated the Django compressor and AWS S3 combo to work; otherwise, all static files would have 404 errored. There are too many combinations in this repository that are going to be missed by the maintainers, and it's up to the community as a whole to fix these things. I'm no maintainer, yet here I am contributing. I find it fair that maintaining a huge package like cookiecutter-django is a monstrous task, but, after learning from maintaining a package all about security, I find it unfair to leave out features as others will come by to help maintain. CircleCI? No one updated the Python version until a recent PR to help reconfigure a Dockerfile was added. If no one maintained cookiecutter-django, no one would be using this library; it's because there are people who use it, and that is why people will keep contributing regardless. |
Beta Was this translation helpful? Give feedback.
-
|
Template repositories is a feature that was introduced around a year ago: https://github.blog/2019-06-06-generate-new-repositories-with-repository-templates/ . I remember looking at it when it got released as it had the potential to replace this project. However, my impression at the time was that it's a totally different approach than cookiecutter. In my understanding, they are a lot more limited than what the cookiecutter CLI is capable of, you cannot pass parameters and handle the multitude of combinations we have in Cookiecutter Django. It looks like we would need one template repository for each combination of options? If so, it's not scalable for our use case. I'm not sure I understand how Github actions would help here... Are you suggesting to re-generate each repo template with a cron? Maybe I'm missing your point, but for now, I'm -1 as well. |
Beta Was this translation helpful? Give feedback.
-
|
Ah ok I guess I'm still not clear:
The purpose is not to have multiple cookiecutter-django that needs to support every new combination. In Facebook, a database like Tao needs to be set up (FB doesn't use Django, but as an example), but Tao isn't published for the public; instead, they add Tao to their own cookiecutter-django repository. It can only be used inside the Facebook infrastructure. The problem is pydanny/cookiecutter-django keeps updating with a bunch of new features or fixes. It's hard to keep up, if at all, with the commits of pydanny/cookiecutter-django; instead, the GitHub action cron job can take any new changes in cookiecutter-django and create a PR in the template repository. An engineer who owns the template repository can merge those PRs to stay up to date with pydanny/cookiecutter-django. That way, they can include their internal infrastructure in cookiecutter.json without needing to leave pydanny/cookiecutter-django's updated versioning and features. |
Beta Was this translation helpful? Give feedback.
-
|
Please don't take this question badly, it's a genuine one, but what outcome are you expecting from this Github issue? It sounds like you're suggesting to have a template repo with a specialised set of option pre-selected. Correct me if I'm wrong, but looks like anyone can do it and own such repo, and I don't see anything to be done/changed in cookiecutter-django here. |
Beta Was this translation helpful? Give feedback.
-
|
It's fine. No option is pre-selected. You can think of the idea as TwitterServer but with the same interface as cookiecutters: select the options you want. The only difference is that, in your repository, you can add other features in cookiecutter.json. The GitHub action just updates your code to match cookiecutter-django (like updating the requirements file). An outcome? Well I'd like to add Elasticsearch and Solr and another internal websocket feature to my own cookiecutter-django since it won't be added here; but if I currently create my own cookiecutter-django (not the fork since GitHub forces it to be public), I won't receive updates from pydanny/cookiecutter-django. If that doesn't make sense, I'll be writing a PR soon; hopefully then it'll make more sense. |
Beta Was this translation helpful? Give feedback.
-
|
@Andrew-Chen-Wang It's my impression that your created template would have a completely unrelated history, and doesn't receive PRs from the original repo. Is the Github Action you mentioned meant to copy the files changed by any commit it sees on the original and copy them over to your new repo? Or do you see a way to copy the commit somehow into an unrelated history? How is that PR meant to be constructed? I'm intrigued by what you suggest, just not clear on these steps:
If there were a clean way to use a template that did somehow receive PRs from the original, that would tip me into the Template Repository camp. |
Beta Was this translation helpful? Give feedback.
-
Yes
Copy the commit changes somehow into an unrelated history. But do I see a way? Sorta, will explain later.
In your template, we run a cron job to see if there are new commits in the cookiecutter-django repo. If there are changes, see if those changes are from a file that still exists in your template repository. If so, check if the file in your template matches the cookiecutter-django file before the changes took place. If so, then replace the contents of your repository's files with the new content from cookiecutter-django (as in a full file replacement). Comparing if the file contents are the same would decrease the potential use case of this. It would make more sense if we could check by chunks in a file rather than by the entire file. Potential use cases of this would be like compose file configurations or package dependency management in requirements. |
Beta Was this translation helpful? Give feedback.
-
Description
This is a difficult effort, especially when thinking about git diffs, but it'd be nice to make this a template repository so that we can have individual "cookiecutter-django" repositories for our own code deployment settings.
We can use GitHub actions to detect every change to master branch and update our template repository's master branch. I think it was raised in the main cookiecutter package, but hasn't been touched since.
Rationale
Everyone has a different configuration that they'd like to reuse, which also may be proprietary code.
Beta Was this translation helpful? Give feedback.
All reactions