

Pinax, rapid web-app development on top of django / python - jacquesm
http://pinaxproject.com/

======
ubernostrum
Headline is a bit misleading. Pinax aims to be:

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.

~~~
iamelgringo
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>

~~~
jacquesm
better like that ?

(was pinax, CMS functionality on top of python / django)

------
joshsharp
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."

~~~
californiaguy
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.

~~~
forkqueue
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.

~~~
californiaguy
> 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.

~~~
forkqueue
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....](http://www.madstop.com/ruby/ruby_has_a_distribution_problem.html)

Basically what I'm saying is don't fear dependencies, embrace them.

~~~
FooBarWidget
> 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.

~~~
forkqueue
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.

~~~
FooBarWidget
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.

------
babul
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?

~~~
alanthonyc
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.

