On Mon, 2009-02-16 at 21:35 -0800, bbeaudreault wrote: > Hello all, > > I am pretty new to Django, and coming from a fairly "protective" > environment in terms of web development. My only experience in webdev > stems from my first job out of college, where I came into a very > complex/robust system and did more tweaking/maintaining than creating. > > I am trying to broaden my horizons, and feel that my background is > sort of tainting my view of how to organize my own server, especially > one in which the framework used is so much different (read: better .. > DRY, MVC) than what I am used to. > > So I created the stereotypical "blog" project, along with using > pluggables such as tagging, django-syncr, etc. to further extend it. > However, as I start to read around, I feel more and more that I really > messed up the organization of that project. > > How I have it set up is like this: > > /mainproject (contains settings.py, etc). > /mainproject/core/ (contains a bunch of core apps that are required > throughout, i.e. I put the tagging and django-syncr apps here, as well > as a people app for users) > /mainproject/contrib/ (contains all the other apps, such as the blog > app, a contact form app, etc) > > This has caused me a good deal of stress, as you probably can > imagine. To start, I have clashing SVN repositories due to the svn > checkout of tagging and django-syncr.
Isn't this just a case of setting of svn:externals correctly? You don't explain how you have things set up, but you should be able to pull in external svn-managed projects fairly easily using externals. If you end up using projects that reside in other source control systems as well, I'd recommend looking at a relatively new project called Pip, which is available through PyPI. It handles similar work to svn:external, but for multiple version control systems (svn, git, mercurial, etc). > Also, I have to add 3 separate > paths to my PYTHONPATH in order to get python to find everything. That's a slight drawback, although it's not too unusual. One python path addition for the settings module, one for external apps and one for internal apps isn't a crazy situation to have. You only have to set up the Python path once per webserver config, after all. > As > I add more sites to this server, and continued the same directory > structure, I would end up needing 3 new entries on the PYTHONPATH for > each project. > > I was thinking of changing this around, to better suit multiple django > projects on one server, as well as simplify my pythonpath and > repositories. > > /home/django/pluggables/ (contains such things as tagging, django- > syncr, any other future pluggables I download) > /home/django/sitename/projectname/ (contains settings.py for that site- > project, templates, apps for that project, etc) > /home/django/sitename/static/ (contains all static content, css, js, > etc) This seems reasonable. The only slight change I would make is to avoid using a directory named django/. You will already have a module called "django" on your Python path (Django's source), so it will avoid confusion when you're reading exception tracebacks and logs to not have another directory with the same name. > How do you guys set up your directory structure, especially for > servers that may host multiple websites using django? > > Is it bad form to use such a directory structure as I have currently > set up? (I am guessing it is, but looking for confirmation or > otherwise) I've seen it in use before. I may have even used it before, I can't remember (I see a lot of different Django setups for various clients, so they all start to blur together after a while). > > Just trying to get some ideas on the most efficient, easily movable/ > extensible way of organizing my projects on a shared server (shared in > the sense that I have multiple sites, not a shared hosting environment > per se, and movable in that how easily I could take one project and > move it to a separate server). Another axis to consider here is the version control aspect. Typically, your settings and Django applications you develop specifically for a project will be version controlled by you. external apps might be pulled from another site and thus use svn:external or some other system. Keeping external versus internal apps clearly distinguishable at a glance is worthwhile doing. It makes debugging a lot easier. You might also want to have a look at the directory structure Pinax uses. They have considered that issue. My personal opinion is that there is a lot of path configuration going on in the various Pinax scripts, which feels a bit uncomfortable, but is a consequence of having lots of external dependencies. And, again, it's something that you mostly only have to set up once (and then document). Worth making as simple as possible, but don't try to go any simpler than that and waste time looking for some non-existent nirvana. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
