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).
Related
diving deeper into django I came across the challenge to handle code which is not specific to 1 app but is shared/used by multiple apps.
I would not(!) like to store it as part of an app (to avoid app dependencies) but to have it in a specific place.
currently my best practice is to create a django app "shared" in which I place this code/functionality
so my project structure looks similar to this:
mysite/
manage.py
mysite/
...
shared
...
app1
...
app2
...
app3
...
...
is there a "django best parctice" or a more practical way how to handle this?
I usually do exact same thing what you are doing. Not sure if that is best practice however I've seen other people using the same approach. I like it because:
when the shared/core/etc app becomes useful in other projects, you can package it as reusable app which can be installed via pip in other projects
it does not interfere with existing apps in the project
The only note about packaging it as a reusable lib is that I would recommend to rename it to something other then shared. The reasons is that when you package it in PyPI lets say as my_django_utils, then you will have to change all your imports in all the projects. If you come up with a generic name now, then you can easily package it in the future without needing to change all your imports...
My answer is inspired by the documentation found in the edx-platform github repository: inter-app-apis
Creating a shared app seems like a good idea. However, its hard to decide whether something really needs to be in a shared app in the early days of development of a project.
If you are sharing only a small set of functionality, rather than trying to completely pull the shared code into a separate app, what if you could make it easy to manage the dependency? One problem with creating any sort of dependency is that they have a way of going out of control and very soon you wont know what parts of an app does your caller depend on.
To address this, you could define a separate python module that acts as a proxy between the app that provides the shared code and the app that calls into the shared code. So if you want your app2 to use some function foo in app1, you don't directly call that function, but you write a wrapper function foo_api in a separate module (called api.py) within app1 which calls the function for you. All functions from app1 that is called by other apps would have to go through this single api layer.
By doing this, you are not eliminating the apps depending on each other, you are making it easier to find the dependencies of an app. And if you later find that there are many callers for a function, then you could think of extracting these into a separate reusable lib.
I have read a few questions about what an "app" is supposed to mean in django, but they go into the general purpose/use of an app, which is important, but not what an app literally "is". For example, I felt my curiosity today when
I deleted a folder that I installed as an app with django-admin startapp, and received a certain error that stackO told me was due to a deleted app name residing in my INSTALLED_APPS. After clearing the name, my app worked again
When making a folder cold (just mkdir, no startapp) in the highest level of a project, when trying to import names from real apps, I have to add my project to the sys.path list to be able to import. After remaking this folder as an app, imports are no longer an issue
I've read questions about this topic that had comments like "OK, I've got a models.py file, so it's an app", and it seems like very few people really understand how an app is started.
My question is,
what leeway do I have to modify the apps django makes? Can I delete all the files that come with it (except init) and make it a cold library with no views and models? Are any files besides init required to function correctly?
What does django do when I run startapp that causes an app to be importable automatically, which effect is not there when I make a folder with an init in it (as I said about needing to add the project path to sys.path within that folder). In other words, what does the django command "startapp" actually do to register an app? The action is in django.core.management.templates.py, I read it today and saw things in TemplateCommand.handle() that refer to app or project names, but couldn't see exactly how it registers them. It imports sys, but searching "sys.module" isn't in the file
If I want to turn an empty directory with init into an app, what do I have to do in the shell to make this change without doing startapp?
Thank you
TLDR: Django apps are just Python packages within your project, and you don't need any file except for __init__.py to import it.
I also experienced this vague explanation of "app" from the Django docs, and it led me to look into what a "web app" in the general scheme was before I could understand the concept of a Django one when I was starting out.
Generally defined, a web application is any program transferred from server to client via a browser. This could be an entire website, a certain component in a website (think captchas, widgets, OAuth, etc.), or a function of a website (such as integration with other technologies, like exporting a page to a PDF). These can be modular components or not, portable or not, and distinct within the project's source code or mixed with other things.
Since the general "web app" definition is quite ambiguous, it may be easier to imagine the "Django app." Your project contains one or more apps, of which some may have files or not. Technically, your app can contain nothing except the __init__.py and still be imported (it's just a normal Python package, albeit a useless one). You can make it a library with other modules, but this seems unpythonic, and I make a point to separate business logic from my website source code whenever possible.
Apps are simply things that do something for your project. A question that many people, including myself, like to ask to define an app, is "what does it do?" If you can't answer this question in a concise manner (that doesn't include "and") then your app could be broken into several different parts. This is recommended for your sake, but you may break this rule if you really want. In my first Django project, I made the entire website inside one app folder. It became a nightmare to manage, but I did it.
Views and models are just places to store the information that you need to use for that app in one place; if there was just one big app for your entire website, things would get cluttered and unmanageable very quickly. That would certainly be unpythonic, and the Django developers are very conscious of making things "correctly."
As for technical specifics, Django projects are packages. You can play around with manage.py startproject and checking your sys.path before/after. Apps are packages as well, which (supposedly) contain modules that allow your "app" to perform its intended function. You can use them for anything, everything, or nothing at all, but they are just a Python package with modules in a neat little folder on your system to do something for your project.
You can find a quick overview of applications in the Django documentation here, if you haven't already. Also, this is all a product of my base understanding, so if there is any problem with any part of my answer, please let me know.
I'm uploading my first Django project to a Linux server, where I should put my project in the filesystem?
With a PHP, or ASP project, everything goes into /var/www, would it be ok to do the same and add my Django project to the /var/www folder?
In the Django tutorial it states:
Where should this code live?
If your background is in PHP, you're probably used to putting code under the Web server's document root (in a place such as /var/www). With Django, you don't do that. It's not a good idea to put any of this Python code within your Web server's document root, because it risks the possibility that people may be able to view your code over the Web. That's not good for security.
Put your code in some directory outside of the document root, such as /home/mycode.
File Hierarchy System
#Andy Hayden really states where not to place ones code. The File Hierarchy System (FHS) implicates the following structure; PATH maps to PACKAGE or PROVIDER (It is recommended that parties providing multiple packages should use PROVIDER/PACKAGE) :
/etc/opt/PATH # FHS location for /opt configuration files
/opt/PATH # FHS location for PROVIDER or PACKAGE name
/var/opt/PATH # FHS location for /opt variable storage
The FHS expects /opt/PATH to contain all the material necessary for the successful execution of ones package so it seems prudent to setup the following symbolic links
/etc/opt/PATH to /opt/PATH/etc
/var/opt/PATH to /opt/PATH/var
This provides a good basis but Django projects have extraneous requirements that the above structure does not fully meet.
Static Files
Static files are deployed when one runs python manage.py collectstatic to the STATIC_ROOT which should point to the web server root for static delivery, usually /var/www/PATH.
One could link /var/www/PATH symbolically to /opt/PATH/static
but this is typically a bad idea; Consider the case that you have a misconfigured server and a user goes to www.domain.tld/../ and copies your work.
Settings
If you created your project with django-admin create-project WEBSITE the you will typically have a setup.py file under the WEBSITE folder.
PROJECT/
WEBSITE/
setup.py
...
If you converted this settings module into a package, or you used some wrapper around django-admin e.g. django-cms-create etc.
PROJECT/
WEBSITE/
settings/
__init__.py # from .settings import *
settings.py
...
You might symlink /etc/opt/PATH to /opt/PATH/WEBSITE/settings instead of /opt/PATH/etc as described above. I can't think of a practical reason for doing so though... YMMV.
Media
Media, typically provided by ones websites users, are placed into MEDIA_ROOT. It seems prudent to map /var/opt/PATH to /opt/PATH/media in this case.
Virtual Environments
/opt/PATH/env seems the most logical location. /var/env/PATH also seems sensible but is probably better suited as a symbolic link to /opt/PATH/env.
Since a virtual environment is neither an application nor a library the locations /opt/bin and /opt/libs would not do for this. /env/ or /pyvenv/ does not conform to the FHS.
Whiskey
If you're using mod_wsgi with Apache the an invocation similar to python manage.py runmodwsgi --server-root /etc/opt/PATH --setup-only is probably preferable since it places the Apache control commands into the FHS compliant locations, granted they are more cumbersome to invoke in this case.
Home
To my understanding /home was traditionally used by PHP developers when they were hosting multiple sites upon the same server. If you're using Django you're probably serving your site from a dedicated machine and this structure looses a bit of favour in this case... YMMV.
In one of the apps of my Django site I require a third-party module/library. I've been reading up on how a good Django project should be structured but it doesn't mention much about storing libraries. My current project is structured like so:
urls.py
manage.py
settings.py
apps
app1
views.py
models.py
manager.py
tests.py
app2
...
...
...
...
Should a create a directory at the top-level named libs and dump it there or should I create a libs directory under the specific app folder that I'll be using this in?
Another thing was that when I code Django, I try and keep my views, models and managers very light. If some complex stuff is needed, I create a class/module and dump stuff there. Should I put this in the specific app folder that I'll be using this in or should this go to libs folder as well? I often have a helpers.py file in my apps but I use that for generally storing quite small and simple helper functions.
One could obviously put the library anywhere. It's all the same to Python but not necessarily the right way to go about this.
Thanks.
If this is a third-party library, it shouldn't be kept in your source code at all.
If you use virtualenv, you get a complete environment that you can install libraries in specifically for that project. Plus, in conjunction with pip, you can set up a requirements.txt file which specifies all the libraries you need to run the project, and installs them in one go when you start on a new machine, or deploy to production.
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/