Re: These waters aren't so friendly after all
On 18-Jan-08, at 4:57 PM, Forest Bond wrote: >>> Then there's Kenneth Gonzales. All I can say is, "hey dude, >>> that's not >>> very friendly." >> >> 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. > > 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. 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/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
Hi,
On Fri, Jan 18, 2008 at 10:30:53AM +0530, Kenneth Gonsalves wrote:
> On 18-Jan-08, at 12:20 AM, LRP wrote:
> > 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.
>
> this will not be on your path - and why debian packagers created that
> weird directory is beyond me
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).
> > Then there's Kenneth Gonzales. All I can say is, "hey dude, that's not
> > very friendly."
>
> 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.
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
Description: Digital signature
Re: These waters aren't so friendly after all
On 17 Jan 16:01, LRP wrote: > > 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. 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
Django generates the shiniest, happiest pages of any web framework... :) http://samfeltus.com/pythonista/MardiGrasPreview.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
On 18-Jan-08, at 12:20 AM, LRP wrote: > 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. this will not be on your path - and why debian packagers created that weird directory is beyond me > > Then there's Kenneth Gonzales. All I can say is, "hey dude, that's not > very friendly." 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/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
> 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. 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...?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
On Jan 17, 4:01 pm, LRP <[EMAIL PROTECTED]> wrote: > 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. 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
Hi, On Thu, Jan 17, 2008 at 10:50:50AM -0800, LRP wrote: > 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. Maybe a little less time writing nautical prose and a little more using the tools Debian has blessed you with ;) : 18:16 [EMAIL PROTECTED] 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 Description: Digital signature
Re: These waters aren't so friendly after all
Hi, On Thu, Jan 17, 2008 at 04:25:30PM -0600, Tim Chase wrote: > > > 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. > > 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? 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 Description: Digital signature
Re: These waters aren't so friendly after all
> 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. 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. > 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. 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 > And more thanks to Jeff Anderson for helpful comments about SVN. I > will indeed explore this further. 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. > 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. 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
> > ...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.0994? 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 > > > H, 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
Re: These waters aren't so friendly after all
James Bennett wrote: Again, folks: please don't rise to the bait ;) I don't know what that means! signature.asc Description: OpenPGP digital signature
Re: These waters aren't so friendly after all
On 17-Jan-08, at 9:42 AM, LRP wrote: > So where do I turn? Pylons? TurboGears? Ruby on Rails? 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/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
Again, folks: please don't rise to the bait ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
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 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.094, None) >>> django-admin.py startproject mysite File "", 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.099994 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 LRP wrote: ...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.0994? 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~--- signature.asc Description: OpenPGP digital signature
Re: These waters aren't so friendly after all
On Jan 16, 2008 11:12 PM, LRP <[EMAIL PROTECTED]> wrote: > > [snipped] > > I fire up Python (2.4.4), import django, and enter django.VERSION... > oops? What's this 0.96.0994? Supposed to be 0.96.1-1. > Well let's try django-admin.py startproject mysite... Whooo ABANDON > SHIP! SyntaxError: invalid syntax. > > 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: These waters aren't so friendly after all
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." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
These waters aren't so friendly after all
...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.0994? 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
