Hi Omer - OK, I think it's time for you to drop this. Thanks for your suggestions, but we're not going to be adding this to Django.
Jacob On Sun, Mar 24, 2013 at 9:32 AM, Omer Katz <[email protected]> wrote: > 2013/3/24 Russell Keith-Magee <[email protected]> >> >> >> On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz <[email protected]> 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 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 >>> does. >>> Allow developers to change settings as they are collected (for example >>> 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 >> [email protected]. >> To post to this group, send email to [email protected]. >> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
