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:
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 inapps/auth/urls.py. All of its templates are inapps/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 ofsettings.INSTALLED_APPSinproject/to discern which views from the apps were available to me. This way, if I takeapps.notesout of myINSTALLED_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.