Re: Proposal: modular django configuration

2010-06-05 Thread Russell Keith-Magee
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

2010-06-05 Thread Vinay Sajip

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

2010-06-05 Thread burc...@gmail.com
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

2010-06-05 Thread burc...@gmail.com
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

2010-06-05 Thread Tom Evans
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

2010-06-05 Thread burc...@gmail.com
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

2010-06-05 Thread Vinay Sajip

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

2010-06-05 Thread ars_sim
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

2010-06-05 Thread Karen Tracey
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.