2013/3/24 Russell Keith-Magee <russ...@keith-magee.com> > > 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? >> > You ignored this point completely. From the design perspective alone, is there something wrong with this patch?
> 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". > If the purpose of django-configurations is (also) make it easier to define the development/production settings split then you can easily deduct that if anyone can implement it in 5 minutes it will also be easier to split development/production settings. django-configurations take the class based approach but you can just as easily load settings from the development package or the production package. If I want to package a django package for debian it is now very easy to add a source that loads the database settings from dbconfig instead of hacking your way around django. If I want to get the database configuration from an environment variable or parse it from a database url (like how dj-database-config<https://github.com/kennethreitz/dj-database-url>does) it also make it much easier. What kind of example do you want? django-configurations, django-debian & django-harness are examples of what I'd like to be able to get almost out of the box. I want to be able to split development settings from production settings in any way I feel that is contributing to my project. I want to be able to package it for deb, rpm and other repositories. I want to be able to load the installed apps from the apps folder by packages and not only by specifying them. These are just examples of things that people already implemented in a hackish way. What example do you want exactly? > 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. > And now give me the long version. Why each of these examples are not valid workflows that people want to use? > > 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. > The default behavior is still there. Go ahead and use it. But those who created these projects disagree with you. They want a different way to load settings becuase they have different needs. Why make it hard on them? Newcomers to a project will still need to learn these workflows and how are they different from the normal django behavior. I have never used feature X of Django but I'm still glad it's there if I need it or because it saves other people some time. > 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. > > So you are claiming that these projects exist because they do not know the one true way to handle settings? There is none. Everyone has different needs. It's like forcing all djangoers to use the same database or the django ORM for that matter. > 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. > See above. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/1M5nfnpba0M/unsubscribe?hl=en > . > To unsubscribe from this group and all its topics, 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. > > > -- 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.
