Cookiecutter-django: Create Automated Update Tool for Cookiecutter Django

Created on 21 Feb 2017 · 13Comments · Source: pydanny/cookiecutter-django

A common request that I see is "how can we update our project to use the current version of Cookiecutter Django". It's not an unreasonable request to make, Cookiecutter Django has some pretty awesome features. However, currently the answers I give are:

"There isn't an easy answer."
"Do a diff between your project and what Cookiecutter Django renders."" Having done this myself and being a core developer, I can attest to how unpleasant and error-prone this process is.
"Write a script that does it for you." Again, having done this, I can tell you it is a pretty challenging process to write and maintain.
"I've got a solution, but I need you to pay me to implement it." Unfortunately, that never goes anywhere. Which sucks because while I have a real solution to the problem, unless I get paid to do the work, it requires much more up-front investment of my all-too-limited free time than I can afford to give. Also, it would be followed by an ongoing amount of time I can't afford to give to maintain the solution.

The more I think about it, the more I want to do Option #4. The problem, of course, is that no one (so far) has been willing to financially support an automatic updating tool. Yet I believe that the problem is common enough that it might be possible to crowd fund a solution.

I'm well aware that @tomchristie made DRF financially maintainable. I don't need the equivalent of full time wages for this, just enough to justify it.

My idea is to:

Run a $1000 kickstarter to start a new project called 'Cookiecutter Django Updater'. If I can't get $1000 of donations for this effort, then it will be clear the interest isn't enough for me to put in the time to do it.
For ongoing maintenance, rely on Patreon to cover the costs of maintaining the tool.
A potential side effect of this idea is that it will help me cover my time and that of the other core maintainers when it comes to resolving issues and pull requests for Cookiecutter Django.

Before I start on any of this I would like some feedback. Here's what I would like:

A :+1: or :-1: attached to this issue depending on if you like it or not.
Any thoughts or feedback that have.

Source

pydanny

👍43

Most helpful comment

Good quality work should be rewarded. I'm the first one to contribute on kikstarter

polinom on 21 Feb 2017

👍5

All 13 comments

Good quality work should be rewarded. I'm the first one to contribute on kikstarter

polinom on 21 Feb 2017

👍5

Do it, but make it at least $2500.

jayfk on 22 Feb 2017

👍2

For ongoing maintenance, rely on Patreon to cover the costs of maintaining the tool.

If you could find a way to make the internal API filesystem agnostic, you could write a service that automatically updates repos and sends people Pull Requests with changes and charge people for using it.

jayfk on 22 Feb 2017

I like this idea, I believe django south used a kickstarter to add DB migrations to the core.

8radm1n on 22 Feb 2017

I think this is a great idea. I agree with @jayfk that you could probably get much more than $1000. In terms of marketing a Kickstarter project, one thing I've learned is that the sooner your get to the 100% funded mark the better. People love being a part of something popular and so it will trend when it gets funded - the quicker the better. Plus, KickStarter makes moneys on projects that get funded, and so they tend to promote popular projects.

I wrote a quick blog post on how I approached the marketing for the second Real Python course -> https://segment.com/academy/archives/the-newest-lean-startup-tool-is-kickstarter/

mjhea0 on 22 Feb 2017

👍1

Maybe we should re-phrase or (even) more clearly specify what the needs are that we need to cover. To make sure we head in the right direction and get the most out of the idea. I believe:

It's really not only about cookiecutter-django; it's about cookiecutters in general (project setups originally generated using the cookiecutter tool).
"Updating" refers to running a replay against an updated cookiecutter (with the original, unchanged values); i.e. integrate _enhancements of the cookiecutter_ into your project.
"Updating" also refers to running a replay against a cookiecutter overriding some of the replay values; i.e. apply _setup changes_ (e.g. add PyCharm configuration, change database engine or version, etc.)

As you wrote, none of the problems to solve are trivial. And it's certainly even less trivial to expand this idea to cookiecutters in general. I do believe though that there must be a single, generic and elegant approach that covers all 3 goals above.

Not sure what you have in mind specifically, but any automation that takes us closer to "fully automatic" is a serious improvement. Hence, I have thought about an approach that calculates diffs and places a PR, which in turn runs tests (provided by the cookiecutter) to verify the changes are working, and which has to be reviewed / signed off manually. -- It's the responsibility of the cookiecutter author then to provide useful tests that catch issues of imperfect changes that result from that approach, and the cookiecutter user to carry them forward to allow for this process to continue to work! As usual, tests should help to get things right.

bittner on 23 Feb 2017

Interesting thoughts, @bittner, here's my counter thoughts:

It's really about just Cookiecutter Django. Adding in every cookiecutter is a gigantic increase in scope. While a fascinating idea, and maybe worth considering in a science-fiction-like future where there is somehow full-time funding for several people, I'm talking about something quite a bit smaller.
"Updating" refers to running a distinct program to update an existing Cookiecutter Django project. That program will run Cookiecutter again in some fashion, possibly a replay, but not definitely.

In my opinion, writing something that relies on diffs for something of any complexity requires a lot more error-prone end-user participation than I want. As I said, I have a solution in mind, but it's not a diff-based one. Of course, it's up to the user to have tests to ensure that the updating system doesn't break their system. 😉

pydanny on 23 Feb 2017

After 3 days this ticket has just 16 👍. This is after me mentioning it multiple times on social media.

What this says to me is that at this time there isn't enough interest for me to try and get this effort started. There's no way a Kickstarter will succeed if I can't get more than 16 responses. Unfortunately, I don't have the time to spend on something that will be a futile effort.

However, with the advent of Django 1.11 and TSD 1.11, conditions for this will be very different in 1-2 months. I'll reconsider this issue on a monthly basis.

pydanny on 25 Feb 2017

Just to chime in here...one of the issues I see with doing even only the cookiecutter-django portion of this is the monolithic nature of the cookiecutter model. If there were, instead, individual chunks added to a recipe (e.g. celery, whitenoise), then the task would be much more modular and the individual components could provide their own "migrations."

This has always been my issue with boilerplates in any environment (dating back to ones I wrote for myself way back when I was doing dBASE II in the 1900's !). Once you've started modifying the generated code, you're done and improvements to the tool are not easily pulled forward into existing projects.

I believe this is why God invented "modules" or whatever they were called way back when...

ssteinerx on 25 Feb 2017

👍1

I'd throw in 200$ myself! Just keep in mind, it should be non-breaking. It would be awesome, if there is a dry run to see all the changes that will be made. Also, I am using Django-CMS instead of pure Django. So for additional Django-CMS support, I can throw in some more money :) I want to use django cookiecutter for all my future projects, it's that awesome (other than occasional code breaking updates/changes).