Primary image for Reusable Django Apps and Forking

Reusable Django Apps and Forking

One of the things that drew me towards Django was the idea of being able to create reusable applications that would sit on my PYTHONPATH instead of copied across multiple sites. Coming from WordPress, the constant security updates that required me to revisit old projects began to drive me mad.

Trouble in Paradise

With some real world Django experience under my belt, I find myself re-using apps all the time, but not how I originally expected. A fair amount of my client work comes from building content management systems, so I started out building a generic app like flatpages but more extendable and a blogging app. I dropped them in my PYTHONPATH and started adding them to INSTALLED_APPS on my projects.

Over time, they evolved and improved, but they started to handcuff me. I started thinking things like, “This would be a great feature for Project X, but it would break Project Y.” I was worrying about backwards compatibility for one-off sites that were already done and paid for. When I started going back into those projects to make them handle new versions of my application, I realized I was right back where I started with WordPress.

Use the Fork

Since then, I’ve started forking many of my apps for individual projects. While at first I thought I was losing all the benefits of reusable apps, I quickly realized they were still there. I can still get a site up and running rapidly by reusing open source and personal code libraries/applications, but now I have the added benefit of being able to customize them to my heart’s content without worrying about past projects. Things that improve the app go into the main repository for reuse in the next project.

Move On

But what about those once great projects that are now running on “legacy” code? Well… I’ve learned to walk away from them. DHH had a great post recently, All code will eventually go stale. It is true and it is OK. It means you’re learning and improving your craft. Unless I have some amazing new feature for the project or changes are requested by the client, I don’t touch it. If I do need to revisit it, a simple diff usually gets it up to date very quickly. I fix what I need to and leave the rest.

For apps that are polished and have a stable API, PYTHONPATH is often the best place for them. Don’t let it handcuff you though. If you need/want to make changes that don’t make sense in the global context, fork off a copy into your project and move on.

Disagree with me or have a different approach? Leave a comment, I’d love to hear about it.

Peter Baumgartner

About the author

Peter Baumgartner

Peter is the founder of Lincoln Loop, having built it up from a small freelance operation in 2007 to what it is today. He is constantly learning and is well-versed in many technical disciplines including devops, …