Re: Changes to django's settings module

[Omer Katz]

Why would you call them magic?
Why does allowing extensibility for those who need it is a bad idea?
You will be doing it explicitly anyway by providing a SettingsCollector 
class to the Settings class' constructor.
If are doing it, you should know what you are doing.
. Is my code harder to debug or understand than the current code? I 
strongly disagree here. The current Settings class clearly violates 
SRP. 
It holds the settings, validates them and collect them. What's not easy to 
understand about SettingsCollector? You can understand by it's name what 
exactly it does.

"The only reason for having these SettingsCollectors in core is to allow 
redistributable apps like django-configurations to do magic. That is, so 
they can say, "Install django-configurations, and suddenly every setting 
can be overridden from the environment!" This seems like a bad idea, versus 
"Install django-configurations, and now you have a new tool in your toolbox 
to put in settings.py that imports from the environment!""
Why exactly this is a bad idea? Since when extensibility is a bad idea in 
software development?
You just say you are against it but you don't provide a good reason other 
than it's easier to explain to others what's wrong if something is wrong.
 The current behavior will stay as the default behavior *at least *until 
Django 2.0 if not forever so "it's easier to explain to others what's 
wrong" is not a valid argument in my opinion.
If you are writing your own SettingsCollector you probably know what you 
are doing.
If we'll introduce other types of SettingsCollectors in Django then we 
won't introduce them in the Getting Started documentation until a very late 
stage so that newcomers can understand the default behavior but that's 
another issue for later on.

For now I want to focus on the pull request itself.
Does the refactoring makes the code clearer in it's intension?
Does it allow extensibility when it is required?
Does it maintain the default behavior for most Django developers?

I believe that the answer to all of those questions is yes it does.

בתאריך יום חמישי, 14 במרץ 2013 23:56:31 UTC+3, מאת Alex Ogier:
>
> All of the changes you describe are what I would call "magic". Magic has a 
> downside: it's hard to understand and debug. As it currently stands, Django 
> has exactly one form of settings magic: there is a DJANGO_SETTINGS_MODULE 
> environment variable that adjusts where the settings are found. This is 
> easy to document and point to. "My settings aren't working, what is going 
> on?" "Check DJANGO_SETTINGS_MODULE." "Why does this setting have this wonky 
> value that's not the default?" "Read the source code to your 
> DJANGO_SETTINGS_MODULE."
>
> Everything you describe is possible to do yourself explicitly if you just 
> want it for your own app. Want to override from environment variables? 
> os.environ.get("VARIABLE", "default value"). Reading from ini files? 
> ConfigParser.SafeConfigParser("my.ini"). The database is tricky because you 
> can't use the ORM without a chicken-and-egg problem, but it would be even 
> more confusing if you *have to* import from django.conf (for BaseSettings) 
> but you *aren't allowed to* import from django.db.
>
> django-configurations sits entirely in front of Django, which is the right 
> place for it to sit. Forcing everything through the narrow bottleneck of a 
> single settings module is *a good thing*. It makes things explicit and 
> debuggable. Other python frameworks have similar bottlenecks. Pylons has a 
> master config file (ini format) that you specify on the commandline, and 
> several python files in expected locations. Flask is less obvious, it has 
> no magic files at all, but at some point you make a project-wide instance 
> of flask.Flask and pass it to WSGI or a ./manage.py you write yourself and 
> you set config on it manually, for example 
> app.config.from_object("myapp.MyConfig").
>
> The only reason for having these SettingsCollectors in core is to allow 
> redistributable apps like django-configurations to do magic. That is, so 
> they can say, "Install django-configurations, and suddenly every setting 
> can be overridden from the environment!" This seems like a bad idea, versus 
> "Install django-configurations, and now you have a new tool in your toolbox 
> to put in settings.py that imports from the environment!"
>
> Best,
> Alex Ogier
>
>
>
> On Thu, Mar 14, 2013 at 3:42 PM, Omer Katz 
> > wrote:
>
>> You haven't referred to the pull request.
>>  The pull request  itself 
>> currently just refactors the settings module in order to have better 
>> extensiblity hooks and to clarify the code.
>> The pull request introduced the SettingsCollector class which allows you 
>> to costumize how exactly the settings are collected.
>> The LazySettings class now accepts a constructor parameter that allows 
>> you to switch the setting

Re: Changes to django's settings module

[Russell Keith-Magee]

On Fri, Mar 15, 2013 at 3:36 PM, Omer Katz  wrote:

> Why would you call them magic?
> Why does allowing extensibility for those who need it is a bad idea?
> You will be doing it explicitly anyway by providing a SettingsCollector
> class to the Settings class' constructor.
> If are doing it, you should know what you are doing.
> . Is my code harder to debug or understand than the current code? I
> strongly disagree here. The current Settings class clearly violates 
> SRP.
> It holds the settings, validates them and collect them. What's not easy to
> understand about SettingsCollector? You can understand by it's name what
> exactly it does.
>
> "The only reason for having these SettingsCollectors in core is to allow
> redistributable apps like django-configurations to do magic. That is, so
> they can say, "Install django-configurations, and suddenly every setting
> can be overridden from the environment!" This seems like a bad idea, versus
> "Install django-configurations, and now you have a new tool in your toolbox
> to put in settings.py that imports from the environment!""
> Why exactly this is a bad idea? Since when extensibility is a bad idea in
> software development?
> You just say you are against it but you don't provide a good reason other
> than it's easier to explain to others what's wrong if something is wrong.
>  The current behavior will stay as the default behavior *at least *until
> Django 2.0 if not forever so "it's easier to explain to others what's
> wrong" is not a valid argument in my opinion.
> If you are writing your own SettingsCollector you probably know what you
> are doing.
> If we'll introduce other types of SettingsCollectors in Django then we
> won't introduce them in the Getting Started documentation until a very late
> stage so that newcomers can understand the default behavior but that's
> another issue for later on.
>
> For now I want to focus on the pull request itself.
> Does the refactoring makes the code clearer in it's intension?
> Does it allow extensibility when it is required?
> Does it maintain the default behavior for most Django developers?
>
> I believe that the answer to all of those questions is yes it does.
>

I'd definitely argue the first point - that it makes the code clearer.

If you break up your settings file using normal Python imports, the order
of evaluation of a settings file is clear, and can be followed by anyone
that understands the normal Python import process.

In order to use your patch, you need to understand how settings modules
will be combined, and in what order, and with what precedence. It relies
upon implicit knowledge of the mode of operation of the collector, rather
than the explicit behaviour of a built-in language feature.

As for the second point -- As I've said previously, I'd argue that yes, it
allows extensibility, but not on any axis that, in my experience, requires
it. I've seen a range of problems related to the structure of settings
files, but none of them require the sort of structure that you're making
easy to achieve here. If you want to propose a way to make it easy to
separate production from development settings, or a way to keep private
settings (like passwords and SECRET_KEY) out of repositories, I'm all ears
-- but I suspect these problems are more an issue of documenting
conventions than of adding features.

The last point is moot - backwards compatibility is definitely required for
any feature going into core, but that doesn't mean that just because a
feature is backwards compatible it will be added to core.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Changes to django's settings module

[Omer Katz]

Doesn't the fact that the patch makes the code clearer is a reason enough 
for a merge (providing that there will be tests attached to it and 
documentation)?
I guess that for a complex project like Django it might not but I still see 
value in this patch for that reason alone.
Well, if you are writing a SettingsCollector you do need to understand 
those things but it's an advanced topic to begin with.
This patch enables to seperate development settings from production 
settings or keep private settings outside by writing a SettingsCollector. 
Why do you think that this patch won't solve these problems? I can easily 
demonstrate how if you wish.
I am suggesting that at some point Django will provide other 
SettingsCollectors and the documentation will help you decide which one you 
need.
Why is it an issue of only documenting conventions if there is a feature 
that will help you achieve your desired settings structure much more easily?

בתאריך יום שישי, 15 במרץ 2013 11:14:31 UTC+3, מאת Russell Keith-Magee:
>
>
> On Fri, Mar 15, 2013 at 3:36 PM, Omer Katz 
> > wrote:
>
>> Why would you call them magic?
>> Why does allowing extensibility for those who need it is a bad idea?
>> You will be doing it explicitly anyway by providing a SettingsCollector 
>> class to the Settings class' constructor.
>> If are doing it, you should know what you are doing.
>> . Is my code harder to debug or understand than the current code? I 
>> strongly disagree here. The current Settings class clearly violates 
>> SRP. 
>> It holds the settings, validates them and collect them. What's not easy to 
>> understand about SettingsCollector? You can understand by it's name what 
>> exactly it does.
>>
>> "The only reason for having these SettingsCollectors in core is to allow 
>> redistributable apps like django-configurations to do magic. That is, so 
>> they can say, "Install django-configurations, and suddenly every setting 
>> can be overridden from the environment!" This seems like a bad idea, versus 
>> "Install django-configurations, and now you have a new tool in your toolbox 
>> to put in settings.py that imports from the environment!""
>> Why exactly this is a bad idea? Since when extensibility is a bad idea in 
>> software development?
>> You just say you are against it but you don't provide a good reason other 
>> than it's easier to explain to others what's wrong if something is wrong.
>>  The current behavior will stay as the default behavior *at least *until 
>> Django 2.0 if not forever so "it's easier to explain to others what's 
>> wrong" is not a valid argument in my opinion.
>> If you are writing your own SettingsCollector you probably know what you 
>> are doing.
>> If we'll introduce other types of SettingsCollectors in Django then we 
>> won't introduce them in the Getting Started documentation until a very late 
>> stage so that newcomers can understand the default behavior but that's 
>> another issue for later on.
>>
>> For now I want to focus on the pull request itself.
>> Does the refactoring makes the code clearer in it's intension?
>> Does it allow extensibility when it is required?
>> Does it maintain the default behavior for most Django developers?
>>
>> I believe that the answer to all of those questions is yes it does.
>>
>
> I'd definitely argue the first point - that it makes the code clearer. 
>
> If you break up your settings file using normal Python imports, the order 
> of evaluation of a settings file is clear, and can be followed by anyone 
> that understands the normal Python import process.
>
> In order to use your patch, you need to understand how settings modules 
> will be combined, and in what order, and with what precedence. It relies 
> upon implicit knowledge of the mode of operation of the collector, rather 
> than the explicit behaviour of a built-in language feature.
>
> As for the second point -- As I've said previously, I'd argue that yes, it 
> allows extensibility, but not on any axis that, in my experience, requires 
> it. I've seen a range of problems related to the structure of settings 
> files, but none of them require the sort of structure that you're making 
> easy to achieve here. If you want to propose a way to make it easy to 
> separate production from development settings, or a way to keep private 
> settings (like passwords and SECRET_KEY) out of repositories, I'm all ears 
> -- but I suspect these problems are more an issue of documenting 
> conventions than of adding features.
>
> The last point is moot - backwards compatibility is definitely required 
> for any feature going into core, but that doesn't mean that just because a 
> feature is backwards compatible it will be added to core.
>
> Yours,
> Russ Magee %-)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to

Re: Changes to django's settings module

[Omer Katz]

By the way,
The fact that I mentioned that this patch can be extended to load packages 
as well doesn't mean it's the only use case.
I asked you guys if you think that this is needed.
It will enable you to split settings as packages per deployment 
(development package, staging package, production package) and split the 
settings themselves by topic through different modules if you want to.

בתאריך יום שישי, 15 במרץ 2013 11:14:31 UTC+3, מאת Russell Keith-Magee:
>
>
> On Fri, Mar 15, 2013 at 3:36 PM, Omer Katz 
> > wrote:
>
>> Why would you call them magic?
>> Why does allowing extensibility for those who need it is a bad idea?
>> You will be doing it explicitly anyway by providing a SettingsCollector 
>> class to the Settings class' constructor.
>> If are doing it, you should know what you are doing.
>> . Is my code harder to debug or understand than the current code? I 
>> strongly disagree here. The current Settings class clearly violates 
>> SRP. 
>> It holds the settings, validates them and collect them. What's not easy to 
>> understand about SettingsCollector? You can understand by it's name what 
>> exactly it does.
>>
>> "The only reason for having these SettingsCollectors in core is to allow 
>> redistributable apps like django-configurations to do magic. That is, so 
>> they can say, "Install django-configurations, and suddenly every setting 
>> can be overridden from the environment!" This seems like a bad idea, versus 
>> "Install django-configurations, and now you have a new tool in your toolbox 
>> to put in settings.py that imports from the environment!""
>> Why exactly this is a bad idea? Since when extensibility is a bad idea in 
>> software development?
>> You just say you are against it but you don't provide a good reason other 
>> than it's easier to explain to others what's wrong if something is wrong.
>>  The current behavior will stay as the default behavior *at least *until 
>> Django 2.0 if not forever so "it's easier to explain to others what's 
>> wrong" is not a valid argument in my opinion.
>> If you are writing your own SettingsCollector you probably know what you 
>> are doing.
>> If we'll introduce other types of SettingsCollectors in Django then we 
>> won't introduce them in the Getting Started documentation until a very late 
>> stage so that newcomers can understand the default behavior but that's 
>> another issue for later on.
>>
>> For now I want to focus on the pull request itself.
>> Does the refactoring makes the code clearer in it's intension?
>> Does it allow extensibility when it is required?
>> Does it maintain the default behavior for most Django developers?
>>
>> I believe that the answer to all of those questions is yes it does.
>>
>
> I'd definitely argue the first point - that it makes the code clearer. 
>
> If you break up your settings file using normal Python imports, the order 
> of evaluation of a settings file is clear, and can be followed by anyone 
> that understands the normal Python import process.
>
> In order to use your patch, you need to understand how settings modules 
> will be combined, and in what order, and with what precedence. It relies 
> upon implicit knowledge of the mode of operation of the collector, rather 
> than the explicit behaviour of a built-in language feature.
>
> As for the second point -- As I've said previously, I'd argue that yes, it 
> allows extensibility, but not on any axis that, in my experience, requires 
> it. I've seen a range of problems related to the structure of settings 
> files, but none of them require the sort of structure that you're making 
> easy to achieve here. If you want to propose a way to make it easy to 
> separate production from development settings, or a way to keep private 
> settings (like passwords and SECRET_KEY) out of repositories, I'm all ears 
> -- but I suspect these problems are more an issue of documenting 
> conventions than of adding features.
>
> The last point is moot - backwards compatibility is definitely required 
> for any feature going into core, but that doesn't mean that just because a 
> feature is backwards compatible it will be added to core.
>
> Yours,
> Russ Magee %-)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Changes to django's settings module

[Shai Berger]

Omer,

To convince the core committers that the patch is valuable, you need to show 
how it improves things. Build examples for the use-cases mentioned in the 
thread, show how they would be done without your patch, and how the presence 
of your patch allows improvements. The main argument against the patch, as far 
as I've seen, is that it doesn't really help with the common use-cases; the 
onus is on you to refute this claim by examples.

(also, using paragraphs will make your mails easier to read).

HTH,
Shai.

On Friday 15 March 2013, Omer Katz wrote:
> By the way,
> The fact that I mentioned that this patch can be extended to load packages
> as well doesn't mean it's the only use case.
> I asked you guys if you think that this is needed.
> It will enable you to split settings as packages per deployment
> (development package, staging package, production package) and split the
> settings themselves by topic through different modules if you want to.
> 
> בתאריך יום שישי, 15 במרץ 2013 11:14:31 UTC+3, מאת Russell Keith-Magee:
> > On Fri, Mar 15, 2013 at 3:36 PM, Omer Katz
> > 
> > 
> > > wrote:
> >> Why would you call them magic?
> >> Why does allowing extensibility for those who need it is a bad idea?
> >> You will be doing it explicitly anyway by providing a SettingsCollector
> >> class to the Settings class' constructor.
> >> If are doing it, you should know what you are doing.
> >> . Is my code harder to debug or understand than the current code? I
> >> strongly disagree here. The current Settings class clearly violates
> >> SRP. It
> >> holds the settings, validates them and collect them. What's not easy to
> >> understand about SettingsCollector? You can understand by it's name
> >> what exactly it does.
> >> 
> >> "The only reason for having these SettingsCollectors in core is to allow
> >> redistributable apps like django-configurations to do magic. That is, so
> >> they can say, "Install django-configurations, and suddenly every setting
> >> can be overridden from the environment!" This seems like a bad idea,
> >> versus "Install django-configurations, and now you have a new tool in
> >> your toolbox to put in settings.py that imports from the environment!""
> >> Why exactly this is a bad idea? Since when extensibility is a bad idea
> >> in software development?
> >> You just say you are against it but you don't provide a good reason
> >> other than it's easier to explain to others what's wrong if something
> >> is wrong.
> >> 
> >>  The current behavior will stay as the default behavior *at least *until
> >> 
> >> Django 2.0 if not forever so "it's easier to explain to others what's
> >> wrong" is not a valid argument in my opinion.
> >> If you are writing your own SettingsCollector you probably know what you
> >> are doing.
> >> If we'll introduce other types of SettingsCollectors in Django then we
> >> won't introduce them in the Getting Started documentation until a very
> >> late stage so that newcomers can understand the default behavior but
> >> that's another issue for later on.
> >> 
> >> For now I want to focus on the pull request itself.
> >> Does the refactoring makes the code clearer in it's intension?
> >> Does it allow extensibility when it is required?
> >> Does it maintain the default behavior for most Django developers?
> >> 
> >> I believe that the answer to all of those questions is yes it does.
> > 
> > I'd definitely argue the first point - that it makes the code clearer.
> > 
> > If you break up your settings file using normal Python imports, the order
> > of evaluation of a settings file is clear, and can be followed by anyone
> > that understands the normal Python import process.
> > 
> > In order to use your patch, you need to understand how settings modules
> > will be combined, and in what order, and with what precedence. It relies
> > upon implicit knowledge of the mode of operation of the collector, rather
> > than the explicit behaviour of a built-in language feature.
> > 
> > As for the second point -- As I've said previously, I'd argue that yes,
> > it allows extensibility, but not on any axis that, in my experience,
> > requires it. I've seen a range of problems related to the structure of
> > settings files, but none of them require the sort of structure that
> > you're making easy to achieve here. If you want to propose a way to make
> > it easy to separate production from development settings, or a way to
> > keep private settings (like passwords and SECRET_KEY) out of
> > repositories, I'm all ears -- but I suspect these problems are more an
> > issue of documenting conventions than of adding features.
> > 
> > The last point is moot - backwards compatibility is definitely required
> > for any feature going into core, but that doesn't mean that just because
> > a feature is backwards compatible it will be added to core.
> > 
> > Yours,
> > Russ Magee %-)

-- 
You received this message becau

Re: Changes to django's settings module

[Aymeric Augustin]

On 15 mars 2013, at 09:22, Omer Katz  wrote:

> Doesn't the fact that the patch makes the code clearer is a reason enough for 
> a merge (providing that there will be tests attached to it and documentation)?


Hi Omer,

This patch isn't only a refactoring; it adds a new feature. Otherwise you 
wouldn't be talking about documentation.

Each feature added to Django creates a burden:
- for users of Django, who must learn to use it;
- for the core team, who must maintain it for the foreseeable future.

To be accepted, a new feature must:
(a) provide benefits that clearly outweigh these costs
(b) not get in the way of future improvements — as much as can be foreseen.

Unfortunately (a) the benefits of your PR still aren't clear and (b) judging by 
the discussion, your abstraction doesn't match very well the needs of most 
users, and I suspect it could hinder further efforts to make per-environment 
settings (the actual problem) easier to define.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Documenting lazy() and memoize()

[Tom Evans]

On Mon, Mar 11, 2013 at 2:50 PM, Tom Evans  wrote:
> Hi all
>
> Someone just asked on users@ "How do I reverse a URL inside
> settings.py". I gave a solution (eventually; got it wrong the first
> time!) using two functions from django.utils.functional, lazy() and
> memoize().
>
> Neither of these two functions are documented. and so aren't part of
> the API - really I shouldn't have been suggesting them.
>
> Is this deliberate? They seem perfectly useful and correct
> implementations of lazy() and memoize(), and for places like this,
> very useful.
>
> If it is not deliberate, I can whip up some documentation so that they
> can become blessèd parts of the API.
>
> Cheers
>
> Tom

Any thoughts on this please?

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Documenting lazy() and memoize()

[Florian Apolloner]

Hi Tom,

On Friday, March 15, 2013 12:11:04 PM UTC+1, Tom Evans wrote:
>
> Any thoughts on this please? 
>

What's wrong with the solution provided by Donald, which is already in core?

Regards,
Florian 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving database backends out of the core

[VernonCole]

My organization just hit a use case where we need MS-SQL support. 

 I am jumping on board, so there are at least two of us who can do
maintenance. 

I must say that I would prefer quasi-supported status (akin to admin 
and geodjango) rather than actually being in the core.  I think it would 
be a better fit for most situations.  We will always be a small minority of
django users.  I would just like some assurance that pull requests needed
to provide good hook support for external database backends got prompt 
attention from the core developers.
--
Vernon Cole

On Thursday, March 7, 2013 6:46:18 PM UTC+1, Jacob Kaplan-Moss wrote:
>
> On Wed, Mar 6, 2013 at 3:22 AM, Marc Tamlyn > 
> wrote: 
> > I don't know why Oracle is included and MSSQL is not [...] 
>
> It's essentially because a group of people made a concerted effort to 
> get the Oracle backend up to snuff (around the 1.0 timeline, I think?) 
> and then committed to maintaining it. Lately the original people who'd 
> made that commitment have dropped off a bit, but there's always been 
> enough attention to keep it up to date. 
>
> If someone -- preferably a group -- stepped up and committed to 
> keeping a MSSQL backend up-to-date in core, I'd be +1 on merging it 
> and giving those people commit access to keep it up to date. 
>
> [This is me speaking personally, not as a BDFL. It'd have to be a 
> discussion, not just my fiat.] 
>
> Jacob 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.