Re: Proposal: modular django configuration
On Sat, Jun 5, 2010 at 2:53 PM, burc...@gmail.com wrote: > On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee > wrote: >> On Fri, Jun 4, 2010 at 11:54 PM, 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. 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. 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? > 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). 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-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.
Re: Proposal: modular django configuration
On Jun 5, 8:08 am, Russell Keith-Magee wrote: > 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 :-) > That's why the YAGNI principle needs to be applied with care ;-) On this topic, though, I fully agree with you. App configuration should always be at the mercy of site-wide (project) configuration, otherwise the app's usability is severely restricted. Maybe that's fine for some of Yuri's apps, but as a general principle, hardwired connections between specific databases and apps sounds broken to me, too. Regards, Vinay Sajip -- 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.
Re: Proposal: modular django configuration
On Sat, Jun 5, 2010 at 2:08 PM, Russell Keith-Magee wrote: > On Sat, Jun 5, 2010 at 2:53 PM, burc...@gmail.com wrote: >> On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee >> wrote: >>> On Fri, Jun 4, 2010 at 11:54 PM, 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
Re: Proposal: modular django configuration
On Sat, Jun 5, 2010 at 3:53 PM, Vinay Sajip wrote: > > On Jun 5, 8:08 am, Russell Keith-Magee > wrote: >> 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 :-) >> > > That's why the YAGNI principle needs to be applied with care ;-) > > On this topic, though, I fully agree with you. App configuration > should always be at the mercy of site-wide (project) configuration, > otherwise the app's usability is severely restricted. Maybe that's > fine for some of Yuri's apps, but as a general principle, hardwired > connections between specific databases and apps sounds broken to me, > too. Hardwired connections between specific databases and apps sounds broken to me too. But I'm talking about providing sensible defaults. -- 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.
Re: Proposal: modular django configuration
On Sat, Jun 5, 2010 at 9:58 AM, burc...@gmail.com wrote: > On Sat, Jun 5, 2010 at 2:08 PM, Russell Keith-Magee > wrote: >> On Sat, Jun 5, 2010 at 2:53 PM, burc...@gmail.com wrote: >>> On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee >>> wrote: On Fri, Jun 4, 2010 at 11:54 PM, 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 u
Re: Proposal: modular django configuration
On Sat, Jun 5, 2010 at 5:07 PM, Tom Evans wrote: Hi Tom, > 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. I did: http://github.com/buriy/django-configurator > 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 These are exactly my hate patterns. The goal of django-configurator was to get rid of them in the projects I have. Btw, you are not yet using the "state of the art" python-based solution: storing different local_settings in the version control system, so do a dynamic import based on computer DNS name. > 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. Sorry, I'm not native speaker. Can't understand what's "hardly a stretch" neither from context nor from dictionary. >>> 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. I am of control. That's why god gave us ability to override. It seems you are not aware what I suggest. -- 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.
Re: Proposal: modular django configuration
On Jun 5, 11:22 am, "burc...@gmail.com" wrote: > > 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. > > Sorry, I'm not native speaker. Can't understand what's "hardly a > stretch" neither from context nor from dictionary. "Hardly a stretch" == "Not exactly difficult" Regards, Vinay Sajip -- 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.
How to pass List to Form Meta Class
Hello All, I am newbie in django and I will very thankful to you if you help me in this regard. I want to pass list of fields from view to Meta class of FormModel. Please check this example. view.py: fields = [name, email, phone] individual_form = IndividualForm(fields) forms.py class IndForm(forms.ModelForm): class Meta: model = Ind fields = ( 'name', 'email', 'phone', ) I want to access view fields list into forms Meta class. I am not sure I can do this or not. Any idea! how can I do this? Regards, -- 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.
Re: How to pass List to Form Meta Class
Please do not crosspost questions to both django-developers and django-users: pick the right list and send the question there. Questions about using Django, such as this one, belong on django-users. Karen -- 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.