Re: Best practice for maintaining the "Django stack"

If you put something in INSTALLED_APPS, it *is* imported, and when you test everything it is also tested. HM -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe fro

Re: Best practice for maintaining the "Django stack"

Thanks to everyone who replied. I'll read up on virtualenv and pip. Oivvio -- http://pipedreams.polite.se/about/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscri

Re: Best practice for maintaining the "Django stack"

On Fri, Aug 13, 2010 at 04:40:06PM +0200, Thomas Guettler wrote: > > What kind of error do you get? Please post the traceback. > ..E.FEEE.E...E.. == ERROR: Does logging wo

Re: Best practice for maintaining the "Django stack"

This is a common issue with South: it sometimes swallows some import errors from other apps. In my case, I get this error with ImageKit when PIL is not installed, or not compiled correctly. About managing Django stack: the best thing you have is virtualenv + virtualenvwrapper and PIP with requirem

Re: Best practice for maintaining the "Django stack"

Hi, I develop on Linux and all my code is in $HOME and the code of django and third party apps are in $HOME, too. The Django SVN branch http://code.djangoproject.com/svn/django/branches/releases/1.2.X/ is checked out to _django1.2.X. And there is a symlink from $HOME/django to _djangoVERSION. T

Re: Best practice for maintaining the "Django stack"

Hi, I'd second that. PIP and virtual env have worked well for me too. You could also combine it with fabric in order to automate the building of different environments, so once you get a stable working environment you can use pip's 'freeze' command to create a requirements file with the exact vers

Re: Best practice for maintaining the "Django stack"

On Aug 13, 2:43 pm, Oivvio Polite wrote: > So I guess these errors are relating to some testing Django and/or > South does per default and that the errors might be due to some version > incompatibility between the Django/South versions I had installed last > year and the ones that are installed no

Best practice for maintaining the "Django stack"

I started playing around with Django sometime early 2009, did the tutorial and got started on a toy project. Then something came inbetween and now, coming back to my toy project I notice that the unit test spit out a lot of errors relating to the migration tool South. I've haven't written any test