Pinax, rapid web-app development on top of django / python(pinaxproject.com)
pinaxproject.com
Pinax, rapid web-app development on top of django / python
http://pinaxproject.com/
4 comments
I agree the headline is a bit misleading.
They have included a number of more CMS-y bits in the development version, however: http://pinaxproject.com/docs/dev/customization.html
They have included a number of more CMS-y bits in the development version, however: http://pinaxproject.com/docs/dev/customization.html
better like that ?
(was pinax, CMS functionality on top of python / django)
(was pinax, CMS functionality on top of python / django)
I have heard anecdotal evidence that Pinax is a real pain to work with, because a lot of the apps are half-complete or not truly pluggable. My friend told me "in the time we've spent trying to get them to work as advertised we could've written it ourselves."
Well.
My personal opinion as someone who works a lot with Django but not (for now, at least) Pinax is that they hit the problem, common in the open-source world, of starting to hit the popularity curve before they were really ready for it. Pinax started getting attention and flattering blog posts and such when there were still several issues to work out with the way Pinax itself was packaged, how applications were vetted for inclusion, etc., etc.
Fortunately, popularity has also brought them plenty of new contributors, which means this stuff either has been worked out (e.g., for things like packaging -- now using pip with custom bootstraps, and requiring every app to be installable through it, which is pretty much the ideal) or is being subjected to a flurry of activity.
My personal opinion as someone who works a lot with Django but not (for now, at least) Pinax is that they hit the problem, common in the open-source world, of starting to hit the popularity curve before they were really ready for it. Pinax started getting attention and flattering blog posts and such when there were still several issues to work out with the way Pinax itself was packaged, how applications were vetted for inclusion, etc., etc.
Fortunately, popularity has also brought them plenty of new contributors, which means this stuff either has been worked out (e.g., for things like packaging -- now using pip with custom bootstraps, and requiring every app to be installable through it, which is pretty much the ideal) or is being subjected to a flurry of activity.
The idea of django pluggables in general is a misnomer. There are very few applications out there that can be plugged in without a lot of extra work. I was hoping that pinax would establish a set of conventions for making this not the case, but it sounds as though there is plenty of room for improvement.
Is it pluggable like a Drupal module, no. But I wouldn't say adding a line to your installed apps, adding a line to your urls, and then creating your template files is a lot of extra work.
I do agree it would be nice if there was a convention for template names and block names from within those templates. Which would reduce the work on the previously mentioned creating of your template files.
I do agree it would be nice if there was a convention for template names and block names from within those templates. Which would reduce the work on the previously mentioned creating of your template files.
> But I wouldn't say adding a line to your installed apps, adding a line to your urls, and then creating your template files is a lot of extra work.
Of course there are some like this. A large majority however, are not thought out well enough to provide any real benefit without the user writing some other glue. The best example I can think of is django-favorites.
The best example of a pluggable that works well though, imho, is django-tagging. It's well thought out, and works well.
Of course there are some like this. A large majority however, are not thought out well enough to provide any real benefit without the user writing some other glue. The best example I can think of is django-favorites.
The best example of a pluggable that works well though, imho, is django-tagging. It's well thought out, and works well.
i have to second that. we've tried having a good time with pinax, it ended being a pita though and we went the roll your own way.
I tried out Pinax last year. It's sort of like Drupal in that it gives you the building blocks for building your own community site or content management solution. It's a great idea, but unfortunately there were a lot of bugs at the time. Anyone tried it recently?
[deleted]
Pinax is a monstrous pain in the ass to install and use for the following reasons:
1) Bad documentation. 2) Bad installer (installer??? Django apps should be installed with cp and tar.) 3) They attempt to bundle everything with their cheeseball installation package yet I still spent 3 hours compiling external dependencies (not just PIL) which was a major pain in the ass. 4) Not compatible with Python 2.4, the default on a huge number of servers and this is not stated anywhere in the docs.
I haven't deployed the code to a production web server with mod python or WSGI but I'm betting it's going to be a major pain in the ass, too.
The Django apps that I've written from scratch, every single one of them, could be tarred and dropped into a working Django 1.0/WSGI environment with zero effort other than setting up the base environment - I know because I've done it many times. In my opinion they should really rethink this concept of an "installer". It's a red herring for productivity and doesn't even do what it says it does because there are external dependencies to compile and a bunch of undocumented details to sweat over.
1) Bad documentation. 2) Bad installer (installer??? Django apps should be installed with cp and tar.) 3) They attempt to bundle everything with their cheeseball installation package yet I still spent 3 hours compiling external dependencies (not just PIL) which was a major pain in the ass. 4) Not compatible with Python 2.4, the default on a huge number of servers and this is not stated anywhere in the docs.
I haven't deployed the code to a production web server with mod python or WSGI but I'm betting it's going to be a major pain in the ass, too.
The Django apps that I've written from scratch, every single one of them, could be tarred and dropped into a working Django 1.0/WSGI environment with zero effort other than setting up the base environment - I know because I've done it many times. In my opinion they should really rethink this concept of an "installer". It's a red herring for productivity and doesn't even do what it says it does because there are external dependencies to compile and a bunch of undocumented details to sweat over.
Dependencies are the exact reason a plain tarball isn't good enough. They're why package management was invented.
For http://kutoken.com/, our Django hosting service, we've spent quite a while packaging Django apps into .deb format, so our users can for example just 'apt-get install python-django-tagging' to have tagging support in their app (for a really simple example). Now I've got used to working with a system like that, I really couldn't go back to individual tarballs and setup.py and the like.
For http://kutoken.com/, our Django hosting service, we've spent quite a while packaging Django apps into .deb format, so our users can for example just 'apt-get install python-django-tagging' to have tagging support in their app (for a really simple example). Now I've got used to working with a system like that, I really couldn't go back to individual tarballs and setup.py and the like.
> Dependencies are the exact reason a plain tarball isn't good enough
If your web app needs complicated deps, it sucks. Which is kind of my point about Pinax.
It's fucking embarrassing that you can simply untar some very complicated PHP applications and they work fine right out of the box on insanely varied versions of php/httpd/db software and with something like Pinax you need to spend 3 hours chasing down bugs and asking people on IRC what the hell is going wrong.
Django was designed to make things easy, not hard.
If your web app needs complicated deps, it sucks. Which is kind of my point about Pinax.
It's fucking embarrassing that you can simply untar some very complicated PHP applications and they work fine right out of the box on insanely varied versions of php/httpd/db software and with something like Pinax you need to spend 3 hours chasing down bugs and asking people on IRC what the hell is going wrong.
Django was designed to make things easy, not hard.
I couldn't disagree more with the idea that it's embarrassing that PHP apps tend to run with just a simple untar and Django projects don't. For me, this highlights some of the weaknesses of PHP - that there is a lack of pre-built libraries out there, and the difficulties in reusing code.
When I first started using PHP god knows how long ago (IIRC PHP 4 was still in beta), one of the things that shocked me was that there was no equivalent to Perl's CPAN. Things are better now, but not that much, and beyond DB libraries there is still far too much reinvention of the wheel in PHP.
Django is very much in the Unix philosophy of code re-use, and anytime you re-use code there are going to be dependencies. Added to this, many apps are going to use Python, non Django-related libraries, creating more dependencies. Any good Django app that's doing anything moderately complex should have a pretty long list of INSTALLED_APPS.
Many rails apps work with a simple untar because they include their libraries in vendor. I'm not a ruby guy, but Luke Kanies (creator of puppet) is, and wrote a great post on why this is stupid - see http://www.madstop.com/ruby/ruby_has_a_distribution_problem....
Basically what I'm saying is don't fear dependencies, embrace them.
When I first started using PHP god knows how long ago (IIRC PHP 4 was still in beta), one of the things that shocked me was that there was no equivalent to Perl's CPAN. Things are better now, but not that much, and beyond DB libraries there is still far too much reinvention of the wheel in PHP.
Django is very much in the Unix philosophy of code re-use, and anytime you re-use code there are going to be dependencies. Added to this, many apps are going to use Python, non Django-related libraries, creating more dependencies. Any good Django app that's doing anything moderately complex should have a pretty long list of INSTALLED_APPS.
Many rails apps work with a simple untar because they include their libraries in vendor. I'm not a ruby guy, but Luke Kanies (creator of puppet) is, and wrote a great post on why this is stupid - see http://www.madstop.com/ruby/ruby_has_a_distribution_problem....
Basically what I'm saying is don't fear dependencies, embrace them.
> Many rails apps work with a simple untar because they include their libraries in vendor. I'm not a ruby guy, but Luke Kanies (creator of puppet) is, and wrote a great post on why this is stupid
Is it? Rails apps have to work on more platforms than just Debian. You can embrace apt-get and make Debian users happy but you'll piss off everybody else. I wouldn't call the decision to vendor stuff "stupid", but "necessary".
I've noticed that most users actually prefer that an app bundles its dependencies because it reduces installation hassle. Some users literally begged me to vendor a certain library because installing it themselves is too much of a pain. Only a select group of vocal Debian users care about enforcing everything through apt.
Is it? Rails apps have to work on more platforms than just Debian. You can embrace apt-get and make Debian users happy but you'll piss off everybody else. I wouldn't call the decision to vendor stuff "stupid", but "necessary".
I've noticed that most users actually prefer that an app bundles its dependencies because it reduces installation hassle. Some users literally begged me to vendor a certain library because installing it themselves is too much of a pain. Only a select group of vocal Debian users care about enforcing everything through apt.
I can only assume you didn't read Luke's article, with which I wholeheartedly agree. The crux - what do you do when you need to depend on non-Ruby libraries? Include the binaries of these? What if they depend on glibc (which they probably will) - do you stick that in vendor too?
You'd be better off shipping whole virtual machine images as your 'application' if that's the route you want to take.
All modern Linux distributions - RHEL, SuSE, Ubuntu and yes Debian too have packaging formats to handle dependencies. It's up to the distributions to package the apps, as a software developer I think you should be shipping just a plain tarball, which lists its dependencies but doesn't include them.
My main point was the idea that Django apps shouldn't have dependencies is wrong. Django is awesome mainly because of the ability to easily build on other apps. Doing this creates dependencies, and there's nothing wrong with that.
All modern Linux distributions - RHEL, SuSE, Ubuntu and yes Debian too have packaging formats to handle dependencies. It's up to the distributions to package the apps, as a software developer I think you should be shipping just a plain tarball, which lists its dependencies but doesn't include them.
My main point was the idea that Django apps shouldn't have dependencies is wrong. Django is awesome mainly because of the ability to easily build on other apps. Doing this creates dependencies, and there's nothing wrong with that.
I did read his article, and I don't agree. He's only considering his own world without recognizing that Rails needs to consider everybody else too.
As for native code, yes that would be a problem, one that hasn't been solved yet. But luckily most dependencies are pure Ruby, and only few libraries depend on native code. Nobody's suggesting vendoring everything all the way up to the kernel, but vendoring a reasonable amount of dependencies does not seem evil to me. I don't see any point in taking an extremist approach of vendoring absolutely nothing, it will piss off a lot of users.
Also, if distributors will package the apps anyway, then why not vendor libraries? Distributors will remove vendored libraries as they see fit anyway. With this in mind it would make more sense to me to vendor libraries, because people who grab the source tarballs are likely users of platforms with no decent package management.
As for native code, yes that would be a problem, one that hasn't been solved yet. But luckily most dependencies are pure Ruby, and only few libraries depend on native code. Nobody's suggesting vendoring everything all the way up to the kernel, but vendoring a reasonable amount of dependencies does not seem evil to me. I don't see any point in taking an extremist approach of vendoring absolutely nothing, it will piss off a lot of users.
Also, if distributors will package the apps anyway, then why not vendor libraries? Distributors will remove vendored libraries as they see fit anyway. With this in mind it would make more sense to me to vendor libraries, because people who grab the source tarballs are likely users of platforms with no decent package management.
In my experience Debian users are generally dorks who have very little concern for how things are done in the real world.
> Django is very much in the Unix philosophy of code re-use
I'm very much in the philosophy of not tying myself to a particular package management system or distribution. Especially not Debian.
If a package has deps, the documentation should state explicitly what they are, what versions are required, and the best way to make the application work with said deps, not attempt to hide everything behind some bullshit "installer" and then not document anything.
I'm very much in the philosophy of not tying myself to a particular package management system or distribution. Especially not Debian.
If a package has deps, the documentation should state explicitly what they are, what versions are required, and the best way to make the application work with said deps, not attempt to hide everything behind some bullshit "installer" and then not document anything.
I mentioned .deb only in passing. The same applies equally to RPM or any other modern packaging system.
The package explicitly specifies the dependencies. I agree custom installers are a very bad idea, but you seem to be arguing against the very idea of having dependencies, which seems crazy to me.
The package explicitly specifies the dependencies. I agree custom installers are a very bad idea, but you seem to be arguing against the very idea of having dependencies, which seems crazy to me.
Wow...this it the first criticism of Django-related anything I've read on HN. Bravo! I welcome more honest critiques.
If Pinax is such a pain, can anyone make any recommendations on what to use/do if you did want to build a social-networking site using Django?
Roll your own.
There are lots of projects (including Pinax) that you can reference to help you figure out how to do things yourself.
http://djangoplugables.com/
...is a site that lists django related projects. You can also just google stuff. There are a bunch more on Google Code and on github.
There are lots of projects (including Pinax) that you can reference to help you figure out how to do things yourself.
http://djangoplugables.com/
...is a site that lists django related projects. You can also just google stuff. There are a bunch more on Google Code and on github.
[deleted]
1. A collection of Django applications which cover the common features of a variety of different types of sites, vetted for functionality/reusability/etc.
2. Some bits of glue to pull together the various applications for different types of sites.
So, for example, you want to build a social-networking site. Regardless of the specific focus of your site there's lots of infrastructure you're likely to need/want because it comes with that territory (user signups, "friending" and other relationships, profiles, ratings, etc., etc.). So Pinax offers a set of pre-vetted apps which provide that functionality, and some bits to make it easier to plug them all together.