...well, the local folks are friendly enough.

Last I washed upon these sands, capsized on the first leg of my maiden
voyage, I was advised that my vessel, django 0.95.1-1, running on
Linux Debian Etch, was a relic beyond salvage.

So back in port, I smash a magnum of champagne across the bow of my
sleek new django 0.96-1.1, running on Linux Debian Lenny, and cheer as
she slides down the weighs.

I fire up Python (2.4.4), import django, and enter django.VERSION...
oops? What's this 0.96.09999....994? Supposed to be 0.96.1-1.

Well let's try django-admin.py startproject mysite... Whooo ABANDON
SHIP! SyntaxError: invalid syntax.

So here I am again... stranded on the sand.

Ok, ok... I know you Windows salts have no sympathy for we who choose
Linux. More's the pity. And we who choose Debian are a still smaller
minority. But, damnit, hold the flame war, in my experience, Debian
has the best package management system on the globe. It let's us
choose stable, testing, and unstable versions of our applications. In
my case, I value stability in my web applications. But 'pears to me
that django doesn't offer that, at least for my crowd.

Indeed, during my previous visit to these climes, one bystander urged
me to download the SVN version of django for the latest and the
greatest. But this advice scares the socks off me. How can I promise
my clients stability when I'm gamboling on the cutting edge? Moreover,
it makes me nervous as heck to consider compromising my file system
with apt-alien files, when apt and aptitude have served me so well
over these five years. Indeed, I've never run into the kinds of
problems of starting up a new application that I've seen with django.

So where do I turn? Pylons? TurboGears? Ruby on Rails? Wait until
django stabilizes sufficiently for conservative folks like me?

Advisories welcomed.

All the best,

Lloyd

Ladies and gents, you'll do everyone a favor if you don't rise to the bait here.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

On Jan 16, 2008 11:12 PM, LRP <ll...@paisite.com> wrote:

django_admin.py is a Python script, you are supposed to run it from the
command line, not from within a Python interpreter session.

Karen

The django svn version is every bit as stable as 0.96.
The way to ensure that nothing breaks, is to do a checkout of the svn
version, and don't continually update it. The only danger with the svn
version is if you update it, and a backwards incompatible change has
been made. These changes are documented, but it can be a chore to
continually update a project as django is updated. If you simply do one
checkout, that problem is averted.

I've never seen a syntax error using manage.py, and I've used 0.96 and
svn for a while now.

When the next official release is released, that would be the time to go
from your locked svn checkout and make any changes for compatibility sake.

I inherited a django app at work that was done by someone who no longer
works here, and I've needed to make only a few changes to get it
current. It was written against 0.96, and I'm updating it to work with svn.

I use django svn in production on my personal server without any problems.

I don't know much about other web frameworks, as django is my first
experience with a framework.

On my own debian box...
canton:~# apt-get install python-django
<snip... all is well>
canton:~# python
Python 2.4.4 (#2, Jan  3 2008, 13:36:28)
[GCC 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import django
 >>> django.VERSION
(0, 96.099999999999994, None)
 >>> django-admin.py startproject mysite
  File "<stdin>", line 1
    django-admin.py startproject mysite
                               ^
SyntaxError: invalid syntax
 >>>
canton:~# django-admin.py startproject mysite
-bash: django-admin.py: command not found
canton:~# django-admin startproject mysite
canton:~# ls mysite
__init__.py  manage.py  settings.py  urls.py
canton:~#

*in debian, it is called django-admin and not django-admin.py
*Call django-admin from the command line. It should be in your path.
*The django 96.099....994 seems to happen to my vanilla django-0.96.1
straight from the tarball. A different way to check the version would be
to open a python interpretor, import django, type django.__file__
that will tell you where the __init__.py is located for django. That is
the file that contains the VERSION variable.
*Feel free to e-mail me off list if you want some help with django
specific to the debian context.

Jeff Anderson

signature.asc < 1K Download

Again, folks: please don't rise to the bait ;)

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

On 17-Jan-08, at 9:42 AM, LRP wrote:

anywhere but django please

--

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Foss Conference for the common man: http://registration.fossconf.in/web/

I don't know what that means!

signature.asc < 1K Download

Hmmmm,

I have that very same version running without syntax errors on Goobuntu,
with all the apts you'd care to get.  To be honest, I downloaded the
tarball, unpacked it and used the Python package management system to
install, which goes something like this:

tar xvzf django-0.96.tar.gz
cd django-0.96
sudo python setup.py install

and voila`...

There is nothing terribly unstable about the bleeding edge of django.  In
many ways, you can expect the SVN version to be most complete as they use
an agile development system and the SVN stuff is a real release.  Python
in use is version 2.43.

I have also had success with django on Mandriva 2008 (with Python 2.51).

A word to the wise... if you want django on windows with that boneheaded
IIS version 6.0 or later, you need version 0.95 with PyISAPIe as an
accessory.

TurboGears would be a terrible choice.  Python does not do well on threads
and has been known to lock up solid when executing a fork() out of a
thread.  Also, unless you feel your webserver should use very little of
your computers resources, the threaded approach of TurboGears may not give
you what you want.  Python folk made a design decision way back to
implement a Global Interpreter Lock that means one thread runs at a time
in any process, even if you have 100 threads and 32 processor cores, one
thread will be running on one processor.  So while TurboGears has a very
short learning curve, it is not really for production performance.

Zope might be the ticket for you if you don't have patience for Django.
The Zope Enterprise Objects running as parallel processes do provide high
performance.  Most people who have used it call ZEO the bee's knees.  Zope
will work with its own production server, or with apache, or IIS up
through 5.0, or even boa.  Zope will work with most databases, and it it
also has its own, called ZODB, and the O is for Object.  The granularity
of the security is unsurpassed, and the support community is large.  Given
all that, for the particular job Django was designed for, nothing can
touch it.

Now, if you care to fall down one level, there are two frameworks of
significance.  SqlAlchemy and Formalchemy.  I have a program which takes
two  command-line parameters and imports Sqlalchemy.  One of the
command-line parameters is the url for the data base, and the other is the
path to a csv (comma separated variable) file.  The program probes the url
to determine which database it is talking to, then looks at the csv,
taking the first row as column names.  Going down the columns, it guesses
the type, then it creates the table and loads it with the data from the
csv.  That program is nothing special, everyone would say, I am sure, but
it becomes special when you discover that it does these things in 98 lines
of code.

So you have:

TurboGears (Threads limits the performance)
Django (Best for web-publishing applications and pretty good at most other
things)
Zope (lots of options, production performance, and huge)
Plone (Content Management on top of Zope)
and then you have the next level down, frameworks....  The most popular are
CherryPy (used by TurboGears), but basically for Programmers
SqlAlchemy/FormAlchemy/Migration, again, for programmers
Spyce (for webmasters--could be combined with a database framework for
some quick development)

If I need something in two hours, I reach for Django.  If I have a longer
time for development, I lean toward SQLAlchemy.

So now you have it from a professional Python programmer who uses linux,
and turns down high-paying jobs for converting free software to Microsoft
.NET.
And, oh yes, I was once the QA manager for a linux distribution.  I am
wondering how you installed that Django you speak of.

Michael

Hello,

Many many thanks for the thoughtful corrections and comments.

Particularly...

Karen Tracey for pointing out my dunder- headed mistake in running
django-admin.py from Python rather than shell command line.

I'm still having a problem since my shell can't seem to find django-
admin.py. I know it's there; found it in /usr/share/python-support/
python-django/django/bin.

django-admin.py is marked as executable, as is it's containing
directory. So now I need to find out why it's not in the search path.
But this is probably a question for another forum.

And more thanks to Jeff Anderson for helpful comments about SVN. I
will indeed explore this further.

And to Michael for a deeply thoughtful comparison of Python web
frameworks. I much appreciate the time and consideration invested in
this reply.

Then there's Kenneth Gonzales. All I can say is, "hey dude, that's not
very friendly."

And as for James Bennet... I can't for the life of me understand what
he's going on about. There were no hidden traps or gotchas intended in
my post.

I very much like what I've read about django. Unfortunately, my first
two attempts to bring it up have been disappointing. So I did exactly
what the tutorial suggested, turned to the experts on django-users.

I welcome correction if I am doing something incorrectly, or even
stupidly. But if there are barriers to adoption by newbies, isn't this
something the community should be aware of?

If my attempt at levity in the midst of a very frustrating situation
offends some, my apologies.

To all... Many thanks again.

Lloyd

Just to prevent other "dunder-headed mistakes", I presume it's
truely named "django-admin.py", not just "django-admin". :)

You might also check that
/usr/share/python-support/python-django/bin [aside:  this looks
like an odd path, but whatever floats your boat :) ]  is in your
system path?

you should be able to either add that directory to your path, or
create a link to it:

   ln -s
/usr/share/python-support/python-django/bin/django-admin.py
/usr/local/bin/django-admin.py

(all one line, in case some mail agent between here and there
decides to break that into multiple lines)

assuming /usr/local/bin is in your system path.

the easiest way is to add it to your shell's configuration file
(usually a .bashrc or .bash_profile though I never remember which
runs in which contexts).

   export PATH=$PATH:/usr/share/python-support/python-django/bin

Yes, running from SVN has both advantages and disadvantages.
0.96 is nice for stability (the API is pretty much frozen), but
lacks MANY nice new features that the SVN Trunk has brought to
the table.  However, if you follow Trunk, you have to watch the
backwards-incompatable changes when you "svn up" to pull down the
latest.

The waters are full of trolls fishing for a fight about their
favorite framework, so the sensitivity to smack it down is pretty
high.  The list is for discussing Django, so if folks come
looking for a fight, they're rapidly smacked down with a request
to take up the issue on someplace like
alt.web.frameworks.flamewar or comp.lang.ruby or some similar
location.  Just think of it as getting unfortunately fingered as
a false-positive.  Sorry you got mis-identified.

When not wearing defender-of-the-list hats, the ML is generally
both friendly and helpful.

-tkc

Hi,

Not a concern.  The .deb copies/links it to /usr/bin/django-admin .

Just type django-admin (with no .py on the end).

-Forest
--
Forest Bond
http://www.alittletooquiet.net

signature.asc < 1K Download

Hi,

Maybe a little less time writing nautical prose and a little more using the
tools Debian has blessed you with ;) :

--------------------------------------------------------------------------- -----
18:16 fab@storm$ dpkg -L python-django | grep '/usr/bin'
/usr/bin
/usr/bin/django-admin
--------------------------------------------------------------------------- -----

Not that the prose isn't cute.

Anyway, if you're going to champion the distribution, you might as well have a
few good reasons to do so.

-Forest
--
Forest Bond
http://www.alittletooquiet.net

signature.asc < 1K Download

Hello,

Wow. This list is not only friendly, it parties!

Thanks to tips from Jeff Anderson, Tim Chase, and Forest Bond, I now
have start-up directories.

The trick: Debian redirects django-admin.py to django-admin. And, as
Forest Bond points out, django-admin is in a shell-executable path.

I much look forward to exploring further to see what I can learn and
accomplish.

I also appreciate Forest's additional Debian tips. There is so much to
learn, and every little bit helps. You're a winner in my book, Forest.

Hmmm, I'm wondering... I'd have little to contribute beyond my
personal blunders, but I'd be delighted to work with any folks who'd
like to prepare a Debian-specific addendum to the on-line Django
tutorial.

Thanks again all,

Lloyd

On Jan 17, 4:01 pm, LRP <ll...@paisite.com> wrote:

Personally, I don't think the tutorial needs distro-specific help - it
would quickly balloon to a much larger size if other packages do it
differently.

The documentation is written assuming you installed it by following
the docs - if you choose to do so in another method, you must adapt to
fit that.

The standard way to deploy turbogears on high performance sites is to
run several multi-threaded turbogears instances on the same box, and
load balance them behind apache, ngnx, or some other reverse proxy
server.

This configuration scales quite well, as you get more concurrency per
process than you would in a single threaded python web server,
(particularly because lots of time is spent in network IO, or dababase
IO, which don't block other threads) and ultimately you get less
memory overhead for the same number of concurrent connections.

Of course, this takes a little bit of work, but you setup a multi-
process TurboGears deployment in a few min.

--Your friendly neighborhood TurboGears man
(he does things only a turbogear can...?)

On 18-Jan-08, at 12:20 AM, LRP wrote:

this will not be on your path - and why debian packagers created that  
weird directory is beyond me

well, I was one of the people who told you *not* to rely on debian's  
apt-get for installing django - django is developing too fast for  
package managers to keep up with. So, if, inspite of everything you  
want to use django, please install an uptodate version without apt-get.

--

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Foss Conference for the common man: http://registration.fossconf.in/web/

Django generates the shiniest, happiest pages of any web framework...

:)

http://samfeltus.com/pythonista/MardiGrasPreview.html

On 17 Jan 16:01, LRP wrote:

Yup - because debian policy dictates that things in /usr/bin should
*not* have an extension telling you which language they're implemented
in (*waves* as the debian python-django maintainer...)

:)
--
Brett Parker

Hi,

Well the tone here is degrading rapidly.

Debian supports multiple Python versions simultaneously, and every Python module
installed via the package manager works with all of the installed Python
versions.  One of the ways it does this is with the "python-support" system.
Here, Python modules are installed in /usr/share/python-support/[package name].
In this case, the package name is python-django, and the "django" directory is
simply the source tree from the django release.  The modules are hooked into
each Python's site-packages directory via .pth files.

It's actually pretty elegant, I've found, and the usual problems associated with
multiple interpreter versions just don't exist on Debian machines (which is
certainly not the case on the RHEL server I've dealt with).

You have to admit that, in the vast majority of open-source projects, it is not
common for end users to run software straight from svn.

Moreover, as a user, I don't trust upstream developers to tell me how to put
software on my Debian/Ubuntu machine.  They are almost always wrong because they
don't know Debian.  On the other hand, I know Debian really well, so I have
pretty good instinct about these sorts of things.

It's a tricky business at first, though, figuring out who to ignore, and when :)

(That said, there is a good point here: if you don't follow upstream's
installation docs, you can't expect upstream to support your installation.)

Now, in this case, I do run straight from svn, but only because I've found that
django makes a good exception to the norm.  The development version is
reasonably stable, bugs get fixed reasonably quickly, and the API is still
changing in a way that I'd rather not be too far behind on.

In fact, if I only use the machine for development, I keep django in
~/lib/python/django.  For production, I put it in
/usr/local/lib/python${version}/site-packages/django.  And I understand that it
is up to me to maintain my PYTHONPATH (which my .bashrc does wonderfully).

-Forest
--
Forest Bond
http://www.alittletooquiet.net

signature.asc < 1K Download

With no offense intended towards Brett, Debian's release schedule
is so slow that even if Brett built nightly packages from Trunk,
they would trickle into Stable and Testing at a snail's-pace.

My solution for easy Django installation on Debian is to

  apt-get install subversion
  svn co http://code.djangoproject.com/...

It comes with the added benefit of giving you Subversion on your
local machine so you can version-control your own code too ;)

You just have to ensure that your $PYTHONPATH points to wherever
Django ends up.  Given that I have several branches of Django
installed at any given time, that's also a nice way to switch
between them for testing.

-tim

On 18-Jan-08, at 4:57 PM, Forest Bond wrote:

as you mention later in this mail, django is a special case. There  
are *only* two apps I run directly from a svn checkout and not  
through apt-get on my debian servers. One is django and the other is  
trac - since I needed the latest and no package was available when I  
installed that. I think that once 1.0 comes out, the devels will then  
standardise the file structure and have best practices for the  
plugins etc etc - then, and only then, would I recommend apt-get for  
django.

--

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
Foss Conference for the common man: http://registration.fossconf.in/web/

On 18 Jan 07:16, Tim Chase wrote:

Raphael generally creates packages following svn at rough milestones
(like when there's something he wants to use) and puts them in
experimental, so it should be possible to track a "fairly" recent
experimental upload. Current version there is svn r6996, which appears
to have been uploaded by Gustavo... so there are users of the
experimental packages :) (At the end of the day, it's down to
preferences... I like running packaged software, and stable releases -
my django work is still mostly against a 0.96 tree...)

I tend to use git for that ;) (and then git-svn to track django, too -
but then I appear to have 99% of version control systems installed on my
machines :/)

That's the better reasoning for not using the packaged version, if
you're supporting multiple different sites against different versions of
django.

Cheers :)
--
Brett Parker