djc.recipe is dead, long live djc.recipe2!

Making the buildout recipe more adherent to how Django is evolving required a rewrite. And it got a lot more simple!

djc_recipedjc.recipe has been the standard way for us to do Django buildouts for over two years.

But, in the meantime, Django has evolved quite a lot, despite the version number passing from 1.1 to 1.4 only. Several new things were introduced: new ways of expressing settings, new settings, the staticfiles app, etc.

Since our recipe strived to make each setting available as a part setting, it was becoming increasingly complex to do so: for example, the LOGGING, DATABASES and CACHES have evolved to be complex data structures that cannot be adequately expressed in a configuration file, while it is extremely simple to express them in pure python.

Furthermore, several features that were present in the recipe, such as the ability to coalesce/copy static files, has been obsoleted by the advent of specific Django apps (django-staticfiles) that were subsequently merged into the core.

We'd like to keep using buildout

However, completely dicthing buildout in favour of a development/deployment standard based on pip and virualenv was unfeasible because:

  • We use, and will keep using, buildout for things like Plone (that can be quite hard, if not impossible, to develop and deploy without it)
  • Maintaining one deployment standard is hard, two is unfeasible
  • After all, we like buildout

Therefore the decision was made to scrap pretty much all the parts of djc.recipe that were causing problems, and keep only the good things.

The good things

The good things left were only a few:

  • Ability to use buildout
  • Having the settings.py file not sitting within the (applicative) code
  • SECRET_KEY autogeneration (because I can't trust myself with coming up with a good one)
  • The ability, for system administrators, to just tweak a buildout file to do the very basic customizations they need (changing ports, database connection settings, cache backends) while leaving all the rest of the settings to the developer.
  • The ability, in extreme cases, to tweak the WSGI app file and the manage file from buildout (setting environment variables, or doing strange manglings of sys.path) from a single point and in a way that is update-friendly (customizing your manage.py isn't)

The rewrite

That's why we decided to start from scratch and, taking our years of experience with the previous iteration, build something that was both more simple and more powerful at the same time.

On the other hand, we realized that a complete rewrite (which is backwards-incompatible with existing installations) couldn't be pushed over as a mere update, and break every unpinned buildout1 out there. So we decided to spin off a new package named djc.recipe2.

What changes

Everything?

Ok, in short, the main changes are that there is no settings template anymore, but instead a real, honest to Python, settings.py file.

This file in order gets imported by another, autogenerated settings file, that simply overrides the SECRET_KEY setting and others you might want to.

The documentation has been made much more easy to read, and it will walk you from setting up your first project to deploying it and then up to advanced use cases.

Conclusion

All in all, we strongly recommend you to use this new recipe if you are starting a new buildout-based Django project.

You can find the source at http://github.com/abstract-open-solutions/djc.recipe2 (with Travis-CI integration).

For new ideas, comments, errata, constructive criticism, insults, flame wars, etc, head over to the google group or write to djcrecipe@googlegroups.com.

 


1 You should always pin every package in your productions buildouts. But sometimes you forget some, and I wasn't feeling like saying "your fault" to someone that suddenly saw his production environment go to pieces. I'm not that Nazi.

Share this on

Share |

On same topics

Comments

comments powered by Disqus