tags:

views:

167

answers:

4

Why aren't they simply directories? Any good advice says to keep as much as possible in the apps and not to couple them to the project. The very ability to import an app as project.application discourages this. Why does django-admin.py create the __init__.py at all? The project is perfectly useful without it. What is the justification?

+1  A: 

We have a single project that we "subclass" of sorts for other projects. So we have other projects that import stuff from the main project. I guess for us it provides the common namespace that contains all the other apps.

We could move to a package with all our apps in it separate from the projects i guess. Our system has grown rather than been planned.

So I guess my answer is, it provides a good root namespace. (for our needs) :)

dpn
Shouldn't applications be outside the project namespace, so as to be re-usable?
ironfroggy
Yep. Hence comment about code growing naturally. Unfortunately as is often the case, features trump fixes like this when it comes to allocating resources. :\
dpn
+1  A: 

There isn't a requirement that apps be inside the project's namespace, to my knowledge. Just that they be on the $PYTHONPATH. As such, they are usable by any other code on the system which shares the same PYTHONPATH.

jonesy
I know and I prefer them outside the project. The problem is that by making the project a package and allowing apps to be nested in it, really bad layouts and path problems can happen easily. What I'm looking for is if there was a specific requirement at the creation of Django that put that __init__.py in there. Going to ask django-users
ironfroggy
A: 

I think the idea is that you can reuse the applications but you don't need to move them from the project where they were initially created. If the project weren't a package you would need to copy/move the application you want to reuse to a python package. Because of that being the project itself a proper python package you can reuse the applications in it without moving the applications to other place.

Julio Menendez
+1  A: 

The core of a project is a settings.py and a root urls.py. Both of those are Python modules, thus they need to be importable somehow. You can put the project directory directly on the Python path and thus make them importable as top-level modules, but that's arguably even worse practice. Better to have the project be a package and the settings and urls be modules within it.

Carl Meyer