[GSOC 2014] Reducing coupling in Django components

[Javed Khan]

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. 

Thanks,

Javed

[Russell Keith-Magee]

Hi Javed,

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 %-)

[Javed Khan]

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 <tuxc...@gmail.com> 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 %-)