My name is Om*e*r and got it. :)
2013/3/24 Albert O'Connor <amjoc...@gmail.com> > 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 < > russ...@keith-magee.com> wrote: > >> >> 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. >> >> >> > > > > -- > ><><><>< Albert O'Connor - amjoc...@gmail.com > 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 > 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.
