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. > 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 . 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.
