If you've been following along, you are probably already aware the Pinax team has decided to make some radical changes to their directory structure based on input from users. I took the time to update my own Pinax project — let me show you what's changed.
First, here's the new directory structure, straight from the README file:
projects/
complete_project/ a complete sample project and templates
basic_project/ a more basic starter project (still to come)
apps/
external_apps/ external re-usable apps via svn:externals
local_apps/ re-usable apps that aren't yet externalized
core_apps/ non re-usable apps specific to sample project
libs/
external_libs/ external libraries
docs/ documentation (in progress)
fixtures/ test fixtures (in progress)As you can see, the application directories have been put into their own structure and a directory for libraries was added. Basically, the space is less flat now.
The projects directory contains sample projects. The manage.py executable in these project directories are designed to automatically include the previously mentioned library and application directories in the appropriate paths.
I've already made the changes to my project to include the new directory structure. What I've done is removed the top level externals (core_apps, external_apps, external_libs, local_apps) and replaced the with two new externals: apps and libs.
Once that was done, I edited my manage.py to accommodate the new directories. Here's a unified diff to give you an idea.
Index: manage.py
===================================================================
--- manage.py (revision 31)
+++ manage.py (working copy)
@@ -2,11 +2,11 @@
from os.path import abspath, dirname, join
from site import addsitedir
import sys
-path = addsitedir(abspath(join(dirname(__file__), '../external_libs')), set())
+path = addsitedir(abspath(join(dirname(__file__), '../libs/external_libs')), set())
if path: sys.path = list(path) + sys.path
-sys.path.insert(0, abspath(join(dirname(__file__), '../external_apps')))
-sys.path.insert(0, abspath(join(dirname(__file__), '../local_apps')))
-sys.path.insert(0, abspath(join(dirname(__file__), '../core_apps')))
+sys.path.insert(0, abspath(join(dirname(__file__), '../apps/external_apps')))
+sys.path.insert(0, abspath(join(dirname(__file__), '../apps/local_apps')))
+sys.path.insert(0, abspath(join(dirname(__file__), '../apps/core_apps')))
from django.core.management import execute_manager
try:The paradigm moving forward is probably going to be to create your new projects in the project directory. If that ends up being the best way to go, we'll cross that bridge when we get to it. For now, this setup is working for us.
Get Slaptijack updates delivered to your Inbox or RSS Reader for free!
The primary reason for this change is that users were getting confused that our sample project was called 'pinax'. We instead wanted to be clear that the directory is just an example of a complete project and we do want to provide multiple such projects.
I think that's a fine idea. This will probably make things a lot easier for folks jumping into Pinax after that change.
I think the new structure will be helpful to all Scott and it's great to see users jumping on board!
What about location and deployment of projects based on Pinax (other that those samples)? Do you expect them to be located at the projects directory as well? If there are two projects on different servers for different clients based on Pinax and you keep them under the same repository, then you wouldn't always like or be able to keep the data and code of one project in another project's server.
@Aidas -
I don't believe the intention is for you to really keep different projects in the projects directory across multiple installations. In other words, if you were deploying a Pinax project at a client location, the only thing in the projects directory would be that client's data.