On Sat, Sep 25, 2010 at 12:46 AM, Chuck Harmston <ch...@chuckharmston.com> wrote: > their project (with the help of a programming language). That is powerful. ...But is not very practical for 90% of django users, who have to invent their own bikes.
> However, that flexibility isn't solely restricted to the method of defining > settings; it could also be applied in the selective determination and > loading of settings. Now, consider the problem you're trying to solve. It > will work great on simple sites that have one development server and one > production server. However, if it is implemented we would be forcing a > specific server setup and workflow on Django's users, and not all Django > projects are deployed in the same way. Why everyone talking about improvement of settings insists on forcing anything and forgets about "backends" way completely? > Django's settings are able to accommodate edge cases like this because they > are generic and flexible. I think you are mistaken here. Writing sites with Python is more flexible than with Django, so why people are using Django? Everyone prefers fine-grained framework to powerful command line and missing libraries! Django settings are kept *simple*, not *powerful*. Backends that support different ways of configurations is what is *powerful*. > You have the power to (and should!) find a solution that makes sense for your > project, as it seems you've done. > However, that sort of thing belongs in a project, not in Django itself. And not everyone agrees on that decision! > On Fri, Sep 24, 2010 at 1:01 PM, Yo-Yo Ma <baxterstock...@gmail.com> wrote: >> >> I read that article. The problem is that it's deployment specific. I >> dint even know what host name "omh.cc" is, but I have a feeling that >> you couldn't work on that from your laptop to your desktop without >> changing something. What I propose isn't a is_production variable. I'm >> proposing an explicit is_development variable so that I can choose my >> settings "explicitly" instead of trying to import something and then >> something else if that's not there. That is very un-pythonic. If I can >> say something to the effect of: >> >> if project.is_dev: >> import dev_settings >> else: >> # is live >> >> just example. I'm not suggesting "project" as a global. It's just to >> show the type of setting I want. >> >> That's much cleaner, and far more explicit than "import os, socket, >> etc". >> >> >> On Sep 23, 7:41 pm, Yo-Yo Ma <baxterstock...@gmail.com> wrote: >> > Thanks for the link David. I'm gonna check it it now. >> > >> > On Sep 23, 6:16 pm, "David P. Novakovic" <davidnovako...@gmail.com> >> > wrote: >> > >> > >> > >> > > This link and the comments suggest some good stuff... particularly the >> > > comment from Malcolm and the original post. >> > >> > >> > > >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p... >> > >> > > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic >> > >> > > <davidnovako...@gmail.com> wrote: >> > > > The thing is, in production mode you normally have to define where >> > > > your settings are anyway, so you pass the unusual settings file name >> > > > there, and just use the regular settings.py for your development. >> > >> > > > So then you are passing the settings configuration information once >> > > > in >> > > > the production server's configuration, not every time you run your >> > > > development server. >> > >> > > > I think people with any decent sized project have addressed this >> > > > issue >> > > > in their own way that suits their own needs. >> > >> > > > For example we have lots of settings files and just import the >> > > > relevant settings into a final file. >> > >> > > > For testing I do what i mentioned in my previous email. >> > >> > > > Like anything on here, you need to ask whether what you are >> > > > suggesting >> > > > would actually be better off as part of the core or if it works just >> > > > fine as something that people can choose to use themselves... >> > >> > > > I think most people use whatever system they are happy with and it >> > > > doesn't get in the way of deployment/development. Thus this fails to >> > > > meet one of the critical requirements for consideration for >> > > > inclusion >> > > > into core. >> > >> > > > D >> > >> > > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma <baxterstock...@gmail.com> >> > > > wrote: >> > > >> Thanks David, but I'm talking about having something built in. For >> > > >> instance, passing a variable to the "Development" server to tell it >> > > >> you're in "Development" seems a bit redundant, no? >> > >> > > >> On Sep 23, 3:39 pm, "David P. Novakovic" <davidnovako...@gmail.com> >> > > >> wrote: >> > > >>> As for running different configs: >> > >> > > >>> manage.py runserver --settings=settings_test >> > >> > > >>> etc.. >> > >> > > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss >> > > >>> <ja...@jacobian.org> wrote: >> > > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma >> > > >>> > <baxterstock...@gmail.com> wrote: >> > > >>> >> I'm simply proposing the idea of having the development server >> > > >>> >> explicitly set something to indicate a "in development" status, >> > > >>> >> so >> > > >>> >> that if that does not exist you can make the assumption that >> > > >>> >> the >> > > >>> >> project is live. >> > >> > > >>> > This is exactly what the settings.DEBUG flag is for. Use it. >> > > >>> > Love it. >> > >> > > >>> > Jacob >> > >> > > >>> > -- >> > > >>> > You received this message because you are subscribed to the >> > > >>> > Google Groups "Django developers" group. >> > > >>> > To post to this group, send email to >> > > >>> > django-develop...@googlegroups.com. >> > > >>> > To unsubscribe from this group, send email to >> > > >>> > django-developers+unsubscr...@googlegroups.com. >> > > >>> > For more options, visit this group >> > > >>> > athttp://groups.google.com/group/django-developers?hl=en. >> > >> > > >> -- >> > > >> You received this message because you are subscribed to the Google >> > > >> Groups "Django developers" group. >> > > >> To post to this group, send email to >> > > >> django-develop...@googlegroups.com. >> > > >> To unsubscribe from this group, send email to >> > > >> django-developers+unsubscr...@googlegroups.com. >> > > >> For more options, visit this group >> > > >> athttp://groups.google.com/group/django-developers?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-develop...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > > > -- > --- > Chuck Harmston > ch...@chuckharmston.com > http://chuckharmston.com > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
