Hi Javed, On Mon, Mar 10, 2014 at 12:08 AM, Javed Khan <[email protected]> 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. 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. 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. 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/CAJxq849U2s8C6FrwkLHSxD8pY45C3rHMShBGHrFnVdkJu%2B3W3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
