My name is Om*e*r and got it. :)
2013/3/24 Albert O'Connor <[email protected]> > Hey Omar, > > Though it may be clear now from this experience, I feel your expectations > about how code becomes a part of Django were incorrect, leading to > some frustration. > > The onus is on the contributor not the core committers for nearly all > aspects of making a contribution, which is likely a difference versus a > smaller open source project. The onus is on the contributor to write the > patch, the tests and the documentation. Not having enough time isn't really > a reason not too, no one is paid to develop Django and no one has much > time. Just sharing code that might be useful is a nice gesture, but one > should not expect it to be picked up automatically. > > The onus is also on the contributor to convince people that the change is > worth while. It isn't the job of the core team to argue why a change is not > worth making, though they often attempt to do so. The default reaction to > change is a conservative one, change must prove why it is useful, not the > other way around. > > Like any open source project Django relies heavily on all the people who > contribute, but in order to make it stable and useful to the huge community > who uses, the process of getting change into it is intentionally somewhat > of an up hill battle where the onus is on the contributor at every stage, > not the project maintainers. > > Albert O'Connor > > > On Sun, Mar 24, 2013 at 7:10 AM, Russell Keith-Magee < > [email protected]> wrote: > >> >> 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? >>> 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 [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. >> >> >> > > > > -- > ><><><>< Albert O'Connor - [email protected] > albertoconnor.ca | watpy.ca | go-opendata.ca > > -- > 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.
