We Keep Coding

Namespace django app names

I have tried searching around for this, but searches including "django", "app", and "namespace" all bring up topics mostly relating to URLConf, not what I want to know.
In Django settings, apps included in a project are listed in the INSTALLED_APPS setting. Most community-released apps are not "namespaced" in that the app name consists of only letters, numbers, and underscores. There are official apps like "django.contrib.sites" that are "namespaced" with dot-syntax. What I cannot seem to find is: how do I do this? For example, if I want to create an app like "mycompany.app". The startapp command of manage.py does not allow naming like this if I try ./manage.py "mycompany.app", complaining of invalid characters.
So what Python and/or Django magic am I missing to create and use apps in this way? Or is there some reason why doing this is discouraged, and I should only make apps like "mycompany_app"?

Create a python package mycompany (i.e. folder with init.py file inside), inside create package app.
There is also namespace term in django urls, can be noticed in calls like reverse('namespace:view-name'), here is the doc for these: https://docs.djangoproject.com/en/1.7/topics/http/urls/#url-namespaces

DjangoCMS: where does it search for plugins?

Cannot you tell me, where and in what order does DjangoCMS search for plugins?
I know that I should add them to INSTALLED_APPS, but what DjangoCMS does with them next?

django CMS searches all cms_plugins.py files in your INSTALLED_APPS. It loads them, thus triggering all plugin_pool.register_plugin calls.
The relevant code is in https://github.com/divio/django-cms/blob/cb836a668b9e53a642a35b768bf60bda39ac03fa/cms/plugin_pool.py#L33 which triggers https://github.com/divio/django-cms/blob/cb836a668b9e53a642a35b768bf60bda39ac03fa/cms/utils/django_load.py#L48
While that is the preferred way of declaring plugins, note that modules imported by Django on startup can also cause plugins to be registered. Should you call plugin_pool.register_plugin in a models.py in an INSTALLED_APP it would also register that plugin, as the models.py file is automatically loaded by Django on startup.

Just like you mentioned INSTALLED_APPS and url configuration and other settings. There is an explanation for how the plugins works in this page plugins.html

What does INSTALLED_APPS setting in Django actually do?

What does this actually do? I recently branched out my project from 1 app into 6 different apps and forgot to update the INSTALLED_APPS part of my settings file. Everything still works even though I didn't list the new apps in. Is that supposed to happen? Do I need to include all my apps in INSTALLED_APPS?

yes.
INSTALLED_APPS helps django to sync the database, run tests, get the urls to work and more related issues.
Maybe your installed apps still works because the main one calls the others with imports, a django app is nothing more that a simple python module that is imported when called in the settings file, that's why you get a invalid syntax error after you run the development server because an import won't work with invalid syntax.

Django sub-applications & module structure

I am developing a Django application, which is a large system that requires multiple sub-applications to keep things neat. Therefore, I have a top level directory that is a Django app (as it has an empty models.py file), and multiple subdirectories, which are also applications in themselves.
The reason I have laid my application out in this way is because the sub-applications are separated, but they would never be used on their own, outside the parent application. It therefore makes no sense to distribute them separately.
When installing my application, the settings file has to include something like this:
INSTALLED_APPS = (
...
'myapp',
'myapp.subapp1',
'myapp.subapp2',
...
)
...which is obviously suboptimal. This also has the slightly nasty result of requiring that all the sub-applications are referred to by their "inner" name (i.e. subapp1, subapp2 etc.). For example, if I want to reset the database tables for subapp1, I have to type:
python manage.py reset subapp1
This is annoying, especially because I have a sub-app called core - which is likely to conflict with another application's name when my application is installed in a user's project.
Am I doing this completely wrongly, or is there away to force these "inner" apps to be referred to by their full name?

You are doing it the right way, since django itself does it that way. The admin app for instance is registered in INSTALLED_APPS as django.contrib.admin, but to reset it you have to use manage.py reset admin, and indeed, manage.py reset django.contrib.admin does not work.
It could be considered as a bug in django...
However, you should not be concerned by name conflicts, because you should always run django inside a virtualenv environment, isolated from the rest of the python installation. This is an immensely more powerful and flexible solution than running django on an ordinary python installation. More info, for instance, here: http://mathematism.com/2009/jul/30/presentation-pip-and-virtualenv/

Large Django application layout

I am in a team developing a web-based university portal, which will be based on Django. We are still in the exploratory stages, and I am trying to find the best way to lay the project/development environment out.
My initial idea is to develop the system as a Django "app", which contains sub-applications to separate out the different parts of the system. The reason I intended to make these "sub" applications is that they would not have any use outside the parent application whatsoever, so there would be little point in distributing them separately. We envisage that the portal will be installed in multiple locations (at different universities, for example) so the main app can be dropped into a number of Django projects to install it. We therefore have a different repository for each location's project, which is really just a settings.py file defining the installed portal applications, and a urls.py routing the urls to it.
I have started to write some initial code, though, and I've come up against a problem. Some of the code that handles user authentication and profiles seems to be without a home. It doesn't conceptually belong in the portal application as it doesn't relate to the portal's functionality. It also, however, can't go in the project repository - as I would then be duplicating the code over each location's repository. If I then discovered a bug in this code, for example, I would have to manually replicate the fix over all of the location's project files.
My idea for a fix is to make all the project repos a fork of a "master" location project, so that I can pull any changes from that master. I think this is messy though, and it means that I have one more repository to look after.
I'm looking for a better way to achieve this project. Can anyone recommend a solution or a similar example I can take a look at? The problem seems to be that I am developing a Django project rather than just a Django application.

The best way that I have found to go about this is to create applications and then a project to glue them together. Most of my projects have similar apps which are included in each. Emails, notes, action reminders, user auth, etc. My preferred layout is like so:
project/
settings.py
urls.py
views.py
...
apps/
emails/
urls.py
views.py
...
notes/
urls.py
views.py
...
...
apps:
Each of the "apps" stands on its own, and other than a settings.py, does not rely on the project itself (though it can rely on other apps). One of the apps, is the user authentication and management. It has all of the URLs for accomplishing its tasks in apps/auth/urls.py. All of its templates are in apps/auth/templates/auth/. All of its functionality is self-contained, so that when I need to tweak something, I know where to go.
project:
The project/ contains all of the glue required to put these individual apps together into the final project. In my case, I made use heavy of settings.INSTALLED_APPS in project/ to discern which views from the apps were available to me. This way, if I take apps.notes out of my INSTALLED_APPS, everything still works wonderfully, just with no notes.
Maintenance:
This layout/methodology/plan also has long-term positive ramifications. You can re-use any of the apps later on, with almost no work. You can test the system from the bottom up, ensuring that each of the apps works as intended before being integrated into the whole, helping you find/fix bugs quicker. You can implement a new feature without rolling it out to existing instances of the application (if it isn't in INSTALLED_APPS, they can't see it).
I'm sure there are better documented ways of laying out a project, and more widely used ways, but this is the one which has worked best for me so far.

You should take a look at :
Django generic relations
Django reusable apps best practices if you want to re-use
GIT or any other CVS (git is great for maintaining + deployment)
Fabric if you need automated deployments/updates
I usually use this project structure :
/djangoproject
/apps
/main # the main code
/static # each sub app can serve statics
/app1
/static # each sub app can serve statics
/app2...
/scripts # manage.py, wsgi, apache.conf, fabfile.py...
/core # your libraries ...
settings.py
local_settings.py
Each app in /apps have an urls.py thats autoincluded in the main urls.py. And each app can be a git submodule (or svn external)
Also, using git, you can work on different parallels branches (master/dev/customerA/customerB...) and merge updates.
Creating real reusable is not so easy with django.

You can extract the common functionality into a separate module and make your apps depend on it:
my_portal
auth_module
profiles_module
application1 (depends on auth_module)
application2 (depends on auth_module and profiles_module)
I think the fact that a 'classical' Django project appear to 'contain' the apps it's using prevent you from seeing the picture - in fact, it's not necessary. For a project where you're going to have some sort of pluggable modules I'd suggest organizing the apps as eggs and using zc.buildout+djangorecipe to manage everything.
This way you'll be able to keep your modules in a flat one-level structure. Eggs have the ability to specify dependencies, so if you install application1 (see above), auth_module will be installed automatically.
Also it'll be easy to have different configurations deployed to different servers. Suppose, you have server1 which has application1 installed and server2 which has both application1 and application2 installed - you can just have two configs:
server1.cfg:
[buildout]
extends = base_deployment.cfg
eggs += application1
server2.cfg:
[buildout]
extends = base_seployment.cfg
eggs += application1
application2
djangorecipe also allows you to specify different settings files for each buildout config so you'll be able to add the necessary bits to the main project's urls and installed apps settings.
Not to mention, you can also have a separate config for development configuration (with debug=True and Django Debug Toolbar installed, for example).