On Monday, 10 March 2014 05:44:19 UTC+5:30, Russell Keith-Magee wrote: > > Hi Javed, > > On Mon, Mar 10, 2014 at 12:08 AM, Javed Khan <[email protected]<javascript:> > > wrote: > >> Hi All, >> >> I'm Javed and I'm currently pursuing a part-time masters in Software >> Systems. I have been involved with django for the better part of the last >> few years and I love the community and ecosystem! In my spare time I try to >> pay back by contributing to django and supporting projects. I love the idea >> of decoupling django and being able to install and use only the forms or >> the ORM. >> >> To try and understand the problem better I've written about the current >> dependencies within django: >> >> http://tuxcanfly.me/visualizing-django-component-dependencies.html >> >> I think django.conf is the most coupled module since it's virtually >> required everywhere to access settings. Similarly a lot of modules are >> coupled to django.apps to access the apps. This is probably because of >> django's assumption about the context of execution i.e. within a project >> created by startproject. Other dependencies are more complex will require >> more analysis. I'll try to find out more and come up with a draft for the >> proposal soon. If anyone has suggestions or if I'm not on the right track, >> please let me know. >> > > It looks like you've got a good start here. You're correct that > django.conf and django.apps are deep dependencies of various parts of > Django, and it's going to be hard to break this dependency. > > Thanks!
> That said, I'd be careful making blanket statements about dependencies > based on dependency graphs. The 'caught my eye' dependencies you found can > all be easily explained. django.templates is dependent on django.http for > one reason - as a base class for TemplateResponse. django.forms is > dependent on django.db because you need to have model introspection in > order to do a model form. Dependency graphs will reveal the existence of a > dependency, but won't demonstrate the reason for the dependency. It's > important you keep the underlying reasons in mind, because we're not > looking to break dependencies at all costs. > > Yeah, I guess that would totally break backward compatibility. I'm not too familiar with this, but IMHO it would be cleaner to have django.forms independent of django.db and inject the dependency when model forms are required. Or maybe take an approach similar to wtforms and have a plugin for doing that instead of a hard dependency. As for TemplateResponse, I'm not sure why it isn't better suited to django.views than django.template since it handles request and returns response. I hope fewer dependencies would make it easier to package and maintain these components. Let me know if there are other options that might be useful instead of obsessing over dependencies. > As far as your proposal goes, my suggestion would be to have a concrete > goal in mind. It's possible that your project might not reach all those > goals, but having an idea of what the ideal end-state would look like would > be very helpful in assessing the merits of your proposal. > Thanks, I need to take a closer look to be able to make a good estimate about the goals but I think there's a plenty of scope to play around with. > > 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/81494501-5f5f-4a29-9a14-73eb73a90567%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
