Re: Use admin.autodiscover() by default?
+1 As this would remove unneccessary frustration. Regards, Valts. On Sat, Jul 19, 2008 at 11:08 AM, James Bennett <[EMAIL PROTECTED]> wrote: > > As of the newforms-admin merge, the IRC channel is seeing a sudden > rush of folks who try the tutorial and complain because the admin > doesn't work. And they're right, because as written the tutorial sets > up the admin in such a way that it's never aware of any models being > registered -- including the contrib models that already have admin > classes. > > Adding 'admin.autodiscover()' to the project's root URLConf fixes > this; normally I'd just check in a quick change to the tutorial to > indicate that this should happen, but it feels to me like the right > thing to do here is instead tweak the project template so that line is > in the default URLConf (but commented out like the rest of the admin > stuff), at which point the tutorial can simply stay as-is. > > Thoughts? > > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Absolute paths in settings.py
It would be useful to have at least this one by default: PROJECT_DIR = os.path.abspath(os.path. dirname(__file__)) Other defaults such as MEDIA_ROOT and TEMPLATE_DIRS also would be useful for me as I repeat these exact lines for every project. Regards, Valts. On Thu, Oct 30, 2008 at 8:44 PM, matt westerburg <[EMAIL PROTECTED]>wrote: > I would like to see this, it seems to be an idiom that most people use. I > know i have to implementent that exact same thing for every project I have > ever done with django. > > > On Thu, Oct 30, 2008 at 1:34 PM, Ole Laursen <[EMAIL PROTECTED]> wrote: > >> >> Hi, >> >> There are a couple of things in settings.py that require an absolute >> path. I don't know about you, but I tend to put all things related to >> a project in subdirectories under the project directory. Thus all the >> absolute paths have the same prefix, the project directory. Rather >> than going trough the hassle of maintaining this by hand, I have begun >> using the following snippet: >> >> PROJECT_DIR = os.path.abspath(os.path.dirname(__file__)) >> >> then for instance >> >> MEDIA_ROOT = os.path.join(PROJECT_DIR, 'media') >> >> and >> >> TEMPLATE_DIRS = ( >># Always use forward slashes, even on Windows. >>os.path.join(PROJECT_DIR, 'templates/'), >> ) >> >> Would it make sense to put this or something like it in Django? >> >> >> Ole >> >> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Absolute paths in settings.py
On Thu, Oct 30, 2008 at 10:23 PM, James Bennett <[EMAIL PROTECTED]>wrote: > Except for the part where it breaks/causes headaches for eggs and > zipped packages, both of which are somewhat popular in this Python > world. There should be significantly greater number of Django projects that are deployed without any fancy stuff involved. Anyway, if someone wants to deploy his project as egg it would be easy to just change "PROJECT_DIR =.." as all other settings might stay the same. Valts. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: floating point django.VERSION element versus adding another element to the tuple
Hello, What is the meaning for the serial number in version_info? Is it some kind of build number? Sorry for the dumb question. :) Anyway, I would be happy for having (major, minor, micro, release_level) tuple as Django version info. Regards, Valts. On Fri, Apr 18, 2008 at 9:52 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-04-18 at 13:28 -0500, James Bennett wrote: > > On Fri, Apr 18, 2008 at 1:21 PM, Jacob Kaplan-Moss > > <[EMAIL PROTECTED]> wrote: > > > That said, I think I agree with Steve's idea of ripping of > > > sys.version_info: we've already stolen so much process from Python > why > > > not add to this list? > > > > The main reason I didn't do that is simply that Python goes a lot more > > fine-grained than I'd ever expect Django to; things like the "micro" > > version number, for example, don't really feel like they'd fit the > > release "schedule" we've traditionally maintained. If it makes lives > > simpler, though, I'll go for it; I just hope nobody ever asks why > > we're not using the microversion ;) > > > > > > Aren't we? Isn't 0.96.1 already using a micro version? Major = 0, > minor = 96, micro = 1. Obviously, that's not where it lives now, > because it doesn't fit in the tuple, but if django goes with a 5-tuple > instead of a 3-tuple, it would be pretty silly to have something like > (0, 96.04, 0, 'final', 0), wouldn't it? > > Cheers, > Cliff > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Maybe DEBUG=True should only record the last N SQL queries?
Hello, +1 from my side. I agree with Simon's proposal and also the email above. It is not really necessary to log *all* of queries also on development servers. If there's something fishy going on nothing would stop me to enable unlimited logging again. Cheers, Valts. On Mon, Apr 21, 2008 at 3:16 AM, Manuel Saelices <[EMAIL PROTECTED]> wrote: > > Simon is right IMO, but not only for production server... what about > development and preproduction servers? Is usual in projects that you > deploy application in a server for customer or partners, and it's > better to set DEBUG mode for debugging purposes (of course), > tracebacks, URLs debugging, etc. I don't like to restart servers every > day/week to avoid a huge memory consumption. > > Regards, > > On 21 abr, 00:40, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > > On Mon, Apr 21, 2008 at 6:23 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > > > > -1 for the reasons that James Bennett stated above. That it crashes > > > and burns in production is actually a feature in this case. > > > > -1 here too, for exactly the same reason. Add to that the inevitable > > Murphyism that the one time you specify N=10 will be the time that the > > 11th oldest query will be the one causing the problem. > > > > Yours, > > Russ Magee %-) > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
