I really like the concept of Pinax, but I’m beginning to see the darker sides of the project. Here’s the fundamental issue:
Pinax does a completely kick ass job of making a combined and base project that pulls together a lot of pretty darn good re-usable django “applications” into a single project. What it doesn’t do well is manage any of the dependencies in that tree, or make it easy to use only a portion of some app. If you want to use Pinax the way Pinax is already developed, you’re rockin’. If not, you’re re-working quite a bit of code. And the worst part is that code is almost all opaque to you and hidden in the pinax framework.
The application I wanted to pull in to my basic “pinax” project was “photos” – some simple photo uploading. Yeah, cool – uses photologue under the covers. What’s not clear is that photos also has dependencies on grouping and tagging, and if you review the dependencies documentation, it looks like there’s circular dependencies embedded in there.
What I ended up doing was to take the “photos” application from the Pinax project directly, fork that, and drop it into my project. Then I had to do a shit-load of renaming and stripping because “photos” is built in to Pinax as a default – so “photos” in my app became “photo” and I was scrambling through code to remove the bindings into commenting, threaded commenting, grouping, and so forth.
I did get it working, and really all told I spent less time stripping out stuff than I would have putting it together from scratch. But the only reason I was able to do it that efficiently is because I’ve already been through the pinax project’s source, had it on my laptop, and was a fairly comfortable and competent Django programmer. Any newcomer hitting this would have been toast, and badly confused.
When I asked around the Seattle Django user’s group related to Pinax, several of them said they’d been shying away from something like Pinax because it was easier for them to simply including the good open-source django apps into their work already. At the time, I thought “Well, maybe that just makes Pinax easier and more effective for newbies into Django.” Now I’m reconsidering.
I don’t have a good answer to the problem, and I’m sure I’ll continue to use Pinax and maybe even dig deeper and see what can be done to resolve this kind of issue. I think the idea of the Pinax project is fantastic, I just wish it was a little less “tightly coupled” under the covers and provided more transparency into it’s depths.
Rhonabwy 
Photos haven’t been touched since 0.5 and so are not a particular good example of Pinax. In fact, I would go so far as saying that stuff in social_project that isn’t used elsewhere is probably not in a good state and should not be considered representative of Pinax as a whole.
LikeLike
Thanks James! That’s good to know. Kind of a pain because it was something I wanted to use – but there ya’ go. If someone *cough* were to go in and dramatically change Photos to make it different or more encapsulated, what would you recommend changing to make it better? I’ve already noticed that the “photos” in the latest dev release is rather significantly different than the 0.7.1 release.
LikeLike
Joe, one of the things we need to do before 0.9 final is start with basic_project and try adding each of the social_project apps *individually* to unravel dependencies. For the most part social_project has remained untouched since 0.5 other than fixing backwards incompatible changes as the core of Pinax has progressed. It needs a lot of work.
LikeLike
I agree. I’ve been working with the .9 alpha and I’ve had to fork almost every app I’m using to get the exact behavior I want.
That said, I really don’t like the idea of Pinax becoming Django for newbies. I think this practice of dropping pinax apps into your own projects is not a great one, but it’s much, much faster than starting from scratch. I recently had to code an app similar to topics from scratch and having pinax-topics as example code made that a lot smoother.
Maybe in future versions of Pinax, instead of just cloning the boilerplate projects for new projects, users will also be able to select exactly which apps they want and which ones they will need to customize.
LikeLike
That’s exactly what I realize when I need to create a blog for a friend. I finally take the blog app, put it into my project and fork it. I think that most of time, Pinax can’t be used directly, but it’s a good working base that expose django best practices.
LikeLike
I think you made a slight mistake in the second to last paragraph: “…shying away from something like Django …” You probably meant pinax in that sentence.
That said, for me the big selling point of Pinax is the tight integration and the ready to use templates in something like social_project. “Concentrate on what makes your site unique.” Instead of reinventing friendship, notifications and so on, I can just start using them and focus on the interesting parts.
Having to fork some apps along the way doesn’t surprise me at all. I never expect Pinax to be the click-together-your-website tool, where in the end I just have to choose the theme and set the homepage name.
LikeLike
Thanks Klaus, you were quite correct. I’ve updated the post.
LikeLike
I think Pinax is at risk of becoming Plone, where if you want to do anything more than drop it in place and set up an admin user to manage content then you pretty much have to start mucking about with undocumented core modules. Plone is what motivated me to abandon Zope, for which I’m eternally grateful.
LikeLike
@Rev Matt
Yes, I think many of us have been “bitten” by Plone. That said, it would be very worrying if people abandoned Django because of issues with Pinax.
The concept of “reusable, pluggable apps” is core to Django, and I worry that this post somehow communicates the impression that “Django is hard to do stuff with and add stuff to, so your only alternative is to take something like Pinax and strip out / rebuild what you need”. Hope not.
LikeLike
Indeed, I stay away from Pinax at all costs, really. The code isn’t stellar and it’s very monolithic. You’re better off pulling in good OSS apps that have few dependencies or common ones.
LikeLike
HI, this is a VERY interesting postm, thanks! James, I really would like to read what yuo wrote here as a warnng in the pinax docs!
LikeLike
talking about manageability of software development and robust customization process (and sending some positive light to plone folks ;)), have a look at Matt Hamilton screencast about how to have plone up and running in less than 3 min on your machine:
secret weapons:
– buildout
– a wonderful community of skilled professionals 🙂
LikeLike
@James, do you have a bug (meta bug) that specifies that adding the apps and cleaning them up should be done – it should be documented so this task isn’t forgotten 🙂
LikeLike
I’m using Pinax 0.9a2.dev13 and it’s kinda cool. Don’t bite the hand that feeds you! Pinax is a groundbreaking project. If you want a better Pinax then submit your patches, guys!
Cheers
LikeLike
I’m going through the same problem with the blog app, i gave up and decided to merge my own project into the pinax code base, as easier, geeez….
LikeLike
I think pinax “modules” are a genuine definition of tight-hardcoded stuff and a bad example of django app reusability 😦
LikeLike