On Sat, Jun 5, 2010 at 9:58 AM, burc...@gmail.com <burc...@gmail.com> wrote: > On Sat, Jun 5, 2010 at 2:08 PM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> On Sat, Jun 5, 2010 at 2:53 PM, burc...@gmail.com <burc...@gmail.com> wrote: >>> On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee >>> <russ...@keith-magee.com> wrote: >>>> On Fri, Jun 4, 2010 at 11:54 PM, burc...@gmail.com <burc...@gmail.com> >>>> wrote: >>>>> Hi Russell, >>>>> >>>>> I strongly disagree with your and Adrian vision of whether conventions >>>>> are good or not. >>>>> But I won't comment that any further. There are your political >>>>> decisions, and I have no single bit of control on them. >>>>> I know that it's impossible to persuade you, so why should I spend my >>>>> time doing this. >>>>> >>>>> However, you didn't tell anything on the problem that was the main >>>>> reason why I wrote this app. >>>>> Additive variables. >>>>> >>>>> DATABASES, DATABASE_ROUTERS, MIDDLEWARE, etc. >>>>> Do you think situation will change with them? >>>>> >>>>> In example, I want few of my apps to work with their own databases. >>>>> They need to install their database into DATABASES and their router >>>>> into DATABASE_ROUTERS. >>>>> >>>>> How would you do that? >>>> >>>> Like Tom said - you don't solve it by configuring the app. You >>>> configure the way a project uses an app, not the way an app should be >>>> used in a project. His example for configuring DATABASES is right on >>>> the money. >>>> >>>> As an example of why the 'app configuration' approach fails, consider >>>> the case of reusable apps. A reusable app can suggest defaults for >>>> settings, but once a reusable app you wrote is in my project, I need >>>> to configure it to conform to my local conditions. Your app *cannot* >>>> know what database it needs to use when it's in *my* project. That's a >>>> project configuration issue for me. >>> >>> Actually, some of my apps know what database they need to use, cause >>> they always use the same databases at the same database server unless >>> these apps are used for development. These are well established >>> applications and they have fixed names for databases (you can override >>> the names, but the names are very specific so you will never need to >>> override the names). >> >> ... until the very first time that you *do* need to. Seriously - you >> simply *cannot* make any assumptions about the deployment environment >> in which a user will be using your app. Every single time in my life I >> have made the statement "Nobody will ever want/need to..." I have been >> proven wrong. Consider it a corollary of Rule 34 :-) >> >>> This is exactly why such app sets its own database options in global.py . >>> And for each development machine I have >>> conf/development_machine1__overrides.py which contains overrides. >>> I believe it's better than having "if socket.getfqdn() == >>> 'development_machine1':" conditions in settings.py >>> >>> But, if *my* app doesn't know what database to use in *your* project, then: >>> 1. It will provide sensible and customizable defaults for app-specific >>> database and app name (let's call them app.LABEL and app.DB) in its >>> own options namespace (yes, GSoC app loading feature will handle >>> that). >>> 2. That variable will be used for its router. >>> 3. Router will add itself into DATABASE_ROUTERS >>> 4. No any settings will be added into DATABASES. >>> And if your used django-configurator, then the rules are pretty simple: >>> 5. Database will be added into the list of the databases in conf/global.py >>> 6. For development machine(s), this database will be overridden in >>> conf/development_machine1__overrides.py >> >> And to all of this, I'd fall back on the Zen of Python: explicit is >> better than implicit. > I can remember "sparse is better than dense" and a line that > namespaces are a good idea. > >> IMHO, this is doubly true when dealing with something as critical as >> configuration -- personally, I want my configuration files to do >> *nothing* surprising or automatic. > It's just a tradeoff between DRY and explicitness, as everything else. > Suggested approach doesn't force you to use automatic configuration. > You may not use it. But why can't I use automatic configuration, > and why 3rd-party plugins creators can't? > This is a question of creditability to this configuration model at all. >
I'm not going to reply again, Russell has quite clearly ruled this out but to reply to these points: As the project manager, you can already use automatic configuration - its python, you can do whatever the heck you like. Your scope is not limited in any way, and if you want to auto-discover default settings from your installed apps, do so. You could even formalize this into a django app, publish it on googlecode and see how widely it is used by people without requiring any changes to django itself. If such a feature where to become standardized, and popular, then it could potentially then be included into django.contrib, but it's completely orthogonal to django itself - this is the benefit of using python for configuration. In our deployments, a project has a default configuration, which is then overridden by a site specific settings_local.py, which is checked out on a site by site basis alongside settings.py. This is then imported into our settings with code like so: try: from settings_local import * except: # It's ok to not have any local settings. pass # Convert INSTALLED_APPS and MIDDLEWARE_CLASSES into lists, # so we can append any extra ones supplied in settings_local.py if EXTRA_APPS: INSTALLED_APPS = list(INSTALLED_APPS) + EXTRA_APPS if EXTRA_MIDDLEWARE: MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES) + EXTRA_MIDDLEWARE It is hardly a stretch to see how this kind of code could be extended to try to import settings_auto or settings_default from each app in installed apps. >> For example - you say that your application needs to run in a separate >> database. My DB Admin (or hosting provider) won't let me have another >> database instance. How does your automated "add this extra database" >> approach handle the case where I don't want you to add another >> database? > Well, in some alternative reality, an app creator might really want to > define a router and a special database because it's cool, not because > it really needs to use its legacy database with its legacy table > names. > > If you're afraid of using configurations incorrectly, you might either: > - turn off auto configuration as a whole > - redefine the DISCOVERY_ORDER as you want. > options.lazy.INSTALLED_APPS is a function. > - override the application option in conf/apps/app.py or > conf/global_overrides.py . It's not fear, its confidence. As the project manager, you should be in control of what configurations are set, not application developers. How do you propose that an application insert middleware? How do you solve the ordering issues for settings like that? These problems aren't insurmountable, but it is just easier to be in control of these settings yourself. How hard is it to read a README and configure the right settings for your project. > > Anyway, it's like saying "we did 4 mistakes already, please don't ask > us to make 5th". > Because, generally, anything implementing observer pattern (django > signals, app templates, templatetags, admin.py files), has the same > problems: > - installation order can make sense > - plugins can inject wrong/unreliable components. > > Hehe, by the way, I want another list of fields for > django.contrib.auth.admin by default, what should I do? :) > > So, it's usually a step forward when you have a component architecture > to use observers for components configuration. > And I agree that observers are one of the most popular ways to make > large software projects overcomplicated, and Java listeners, C++ > constructors and Ruby method injections are known leaders there. > > So I just don't understand why settings can't be implemented as > provider/subscriber if most users will benefit from it. > >>> As alternative, maybe, do we need a registry for routers instead of >>> settings variable? >>> The same question should be asked for other additive variables in >>> settings.py of course. >> >> Again, I don't see why. IMHO we should be letting the end user >> configure their site, not try to impose a semi-automated partial >> configuration gathering scheme, and then provide a scheme for the end >> user to override the default autoconfigured setup (and trust me - no >> matter what scheme you propose, there *must* be a way to override it, >> because it doesn't matter how smart you are - someone out there will >> have needs that step outside the capabilities of your implementation). > Sure, there is a way to override it. Please see above. > (But does this change anything?) > > -- > 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.
