On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz <omer.d...@gmail.com> wrote:
> You are contradicting yourself. At first you said that it does make the > code clearer. Now you say it doesn't. > My apologies -- I've apparently used an English idiom that doesn't have an obvious meaning. When I said "I'd argue the point that it makes the code clearer", that means "You said it was clearer, I disagree, and I'd be willing to defend my position." I do not believe that your proposed patch makes the code clearer. Ok, you guys are right. I'm adding a new feature. > If you think my new design isn't good enough do tell me why. I'll improve > it/change it completely. > It now doesn't violate SRP, it allows flexability for those who need it > and maintains backward competitability. What else is missing here? > I feel a bit like a broken record here because I did specify over and over > what's the purpose of this change. > I don't want to load settings from a class.* I'd like to provide > extensibiloty points in order to help implemet other workflows that people > use.* > And at this point, I'm also feeling like a broken record. The point that I, and several other people have made repeatedly is that we fail to see how these extensibility points would be used in practice. You haven't demonstrated a use case where what you describe would be helpful. Saying "It makes it easier to implement django-configurations" isn't a use case. A use case here might be "it makes it easier to define the development/production settings split". The purpose of this patch is to: > > - Allow developers to implement different workflows for loading > settings for different environments (class based settings, different > modules, different packages). > - Allow developers to load settings from other sources like > django-debian <https://launchpad.net/django-debian> does. > - Allow developers to change settings as they are collected (for > example django-harness <https://bitbucket.org/neithere/django-harness>does > multiple things like this). > > There are usecases, some people actually implemented those outside of the > framework and I don't see a reason why they should. We're perfectionists > with deadlines right? There's no reason to write django-configurations if > in five minutes you can get the same result out of the box. > Do you see value in django-configurations, django-debian or > django-harness? > In short? No. Adding an extensibility point is only beneficial if you actually want that particular axis to be extensible. It's good that Django has an extensibility point for database backends -- that allows someone outside core to develop a backend for DB2 or MSSQL. However, I don't see the benefit in having an extensible mechanism for defining settings. Settings are settings. There should be *one* way to define them, and that's it. There's *benefit* in there only being one way to define settings, because that means that someone coming to a project for doesn't need to discover, and then learn, about a whole other way of defining the fundamental feature the settings for a Django project. Are the problems with Django's settings framework? Yes. Are there areas that would benefit from more documented "best practice" conventions? Absolutely. Does any of this require a flexible framework for altering the way Django loads settings? Not as far as I can make out. Then you must see the value in this patch. You can implement all of those > in an hour tops including documentation and tests with it. > If you don't, just keep using the default behavior. No harm done. > > What exactly is the maintainance burden here? > There is code that can break. There is a publicly documented interface that, once added, we must support into the future. If we ever want to make a change to the way settings are handled (and we do, if you watch the video I linked), we would also need to support this interface going forward. Once a new feature is added, someone may ask for additional tweaks to that feature. Someone may attempt to use that interface in an unconventional way, forcing us to work out whether that usage is supported or not. And on top of all of that, we're fracturing the community position on "how do you define settings". Instead of being able to tell someone, "go look in settings.py", we have to say "Go find out what settings loading mechanism the project has, and then consult the documentation on that". *That* is the maintenance burden. > Instead of saying "Check the DJANGO_SETTINGS_MODULE" you now just need to > ask "Have you written a new collector or loader? No? Check the > DJANGO_SETTINGS_MODULE". > > You want to change how settings are being loaded by default? How does that > contradict the use of my patch? > In fact it makes it much easier because now you can just rewrite the > collector and loader and you have a new default way of loading settings. > > I know there were talks about changing how settings behave and that's why > I did something about it. > > Am I clear enough now? > What is clear to me is that you would like to use django-configurations (or an analog of it). My question to you -- Why do you want to use django-configurations in the first place? What problem is it solving? Then lets focus on solving *that* problem. I'd be very much surprised if the solution involves introducing a pluggable mechanism for loading settings. 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.
