A namespace for installed apps

[Marinho Brandão]

I wrote the task #6275 and Adrian told to create another task with details, so, below I will try to be more clear this time, but I would you be comprehensive with me because my english is not the same lavel of yours.

First at all, I wish to say this issue is firstly for the requirement, but in the end I will say what I think is the thin solution - what does not necessarily is the better way, but it's what I think can fix the problem.

The Requirements

---

Django developers are good to improve adaptable design patterns. We have lot of examples: if you wanna get the value of some setting, you simply import django.conf.settings and all the project variables will be available. The same is true for most of features in the framework: everything has a simple (and/or generic) way to do. This makes the framework uncoupled and flexible.

But this is not truth to installed apps in the project: they must be in the INSTALLED_APPS and we have to integrate between them by a hard way, and each user has its own best way to put the apps in and use them.

What happens is: if we wants to allow people to create plugabble apps (with zero of coupling), we must to give once way to access the installed apps in a project. This free people to install apps from everywhere they want: eggs, .pyc files, in python-path, etc. doesn't matters: the guy will have once (and simple) way to access installed apps.

This feature will allow two (or more) uncoupled apps to tell between them, with no worry about the place they are because everybody will import other apps by the same way. This turns possible simplest way to maintain a common apps repository, each project installed the apps it needs, or some app can be in the site-packages, doesn't matters: every apps will be used always by the same way.

The Solution

---

As I said before, I am trying to say the feature we need - and I know that people like Malcolm, Simon, Jacob, Adrian, etc. are great programmers that has many good ideas, maybe my solution is not the better. But I think the solution with minimum impact is create a file django/apps.py with code to receive importing requisitions and return the app, like below:

("somebody" says)
from django.apps import my_blog

(and the django/apps.py does)
for app in INSTALLED_APPS:

if app.split('.')[-1] == my_blog: return app

I am in a PC with no Django installed, but until later today I will send a patch to be more clear about this solution: it's light and resolve the problem, I believe.

Is this it.

[Marinho Brandão]

Well... as I promised, this is the patch with my proposal.

Is this the killer solution? Definetely: NO. But fix the point about a common way to communication between applications. Not fix all the domain of pluggable applications, but is more one step to do.

Maybe this patch is not a good idea, I believe many developers here are better than me, so, I would be happy if somebody has a better idea, but I ask, please: consider my point of view.

I will lauch another ticket in the same domain, not related in all but in the same way to give adapter-design-pattern-like power to apps. I think this an important thing to make big projects like ERP with Django :)

[jefurii]

If I understand marinho's post, he is proposing another way to add reusable apps. There's already a procedure for this, described by James Bennett in {​http://www.b-list.org/weblog/2007/mar/27/reusable-django-apps/ a blog post} and in {​http://www.b-list.org/weblog/2008/mar/15/slides/ a presentation given at PyCon2008}.

[Marinho Brandão]

@jefuri

no, you not understood, but this ticket is quite the same thing of I said: #3591, other way to do the same. This is enough to say ;)