On Tue, Mar 18, 2014 at 1:56 AM, Clement Robbins <[email protected]>wrote:
> Hello, there! I am a rising junior double majoring in Computer Science and > Economics at columbia university. I am an avid django user and would love > to work on django through google summer of code. > > The topic that piqued my interest from the ideas pages was 'Reducing > coupling in Django components'. As the topic states, this is a huge > undertaking. I have seen some other proposals in this vain that are calling > for creating entirely separate packages for the orm, forms, templates, etc. > The major critique is that it is a massive project for little potential > gain (especially by a gsoc applicant who may not be able to maintain an > extraneous package in the future). > To clarify - I wouldn't expect that the end result of that sort of refactoring would be a standalone package that required independent maintainership. I'd expect to see a change in the way Django itself is built in released, so that the core project is in a position to distribute decoupled packages, and our build system ensures we don't accidentally reintroduce dependencies that have been broken. > I would like to decouple the django orm as much as possible in situ, > instead of trying to create a separate package. In this way, the project as > a whole could move towards packaging apps separately in the future. > > A major complaint that I have seen is its reliance on django settings. I > do not think this portion of the project would be terribly difficult though > it may take some time. > Sorry - you just made milk come out my nose :-) Unless you've got a concrete proposal, this sort of comment is going to get laughed at. Breaking the dependency on settings is most definitely a many-splendoured yak. Actually, it's a family of yaks, who keep Old English Sheepdogs as pets. People with a lot more Django experience than you have gone mad in the attempt. :-) Unless you're framing the question very carefully, or you've got a very specific interpretation of what "breaking the reliance on settings" means, I would easily expect the *design* work for this to take the full 12 weeks of the SoC. > I also notice that the orm is dependent on core and utils. I think the > dependence on utils in probably necessary, but that there is some work to > do getting core out of there. Part of the topic discussed coming up with a > strategy for decoupling of components. Perhaps, as I work, I could come up > with a ideal hierarchy of packages to use as guide when people are cleaning > up or adding to packages. Is there any sort of consensus or on going debate > on how this should be done? I have a few ideas, but would like to better > investigate before I get too set on any one way. > > One of my main worries is the scope of the project. Do people think this > is too much or too little work to do in one summer? > Well, it's a little difficult to judge based on the information you've provided. It isn't clear what you're expecting to achieve as a result of your work. You've said you're not aiming to create a separate package - so what *are* you trying to do? What's your end goal? What constitutes "success"? The problem we have isn't naming of packages, or the structure of the hierarchy. It's about how the code itself is interdependent on other parts. If we put all the ORM code in a single package, we'd still have the same problems we have today. How are you planning to address *those* problems? > I am begging for critique; Anything will be helpful. Also, linking to any > ongoing conversation about any of this would be helpful. > There was a recent thread on django-developers about the "Unsettings" project - if you want a guide for how much work is involved, and the controversies involved, that's a good place to start. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq849SrUh8y0fptaFKQRZaUZ1CmAUw-JwYOS6DiHV61wPnkg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
