If we're talking about the lowest common denominator and keeping things simple, this is what I think we'd have:
myapp1/ myapp2/ myproject/ -django.wsgi.sample -manage.py -management/ --commands/ ---myproject_mycommand.py.sample -media/ --myproject/ ---readme.txt -models.py -settings.py -static/ --myproject/ -templates/ --myproject/ -templatetags/ --myproject_tags.py.sample -urls.py -vendor/ --readme.txt -views.py otherapp1/ otherapp2/ Basically it's what we have now plus three things, samples of common optional files (which could include a link to the relevant docs page so people can get started right away), suggestions for naming conventions (use the app name as a prefix to avoid clashes with other apps) and a vendor folder for 3rd party reusable apps: - a sample wsgi wrapper - a sample management command showing that management commands should be prefixed with the app name to avoid clashes with other apps - a readme.txt reminding people that the media folder is for uploaded content (not static content) and suggesting that they use an `upload_to` value of `app_name/model_name/field_name` on their model file and image fields as a starting point - a static folder showing that static content should be placed in a folder named after the app to avoid clashes with other apps - a templates folder showing that templates should be placed in a folder named after the app to avoid clashes with other apps - a sample template tag library showing that template tag libraries should be prefixed with the app name to prevent clashes with other apps and suffixed with "_tags" to prevent quirky import issues (e.g. myproject_tags.py, myproject_form_tags.py) - a vendor folder that is automatically added to the python path (at the beginning, or after the project folder) and a readme.txt explaining that 3rd party reusable apps or specific versions of apps that exist elsewhere on the system should be placed here and imported with `from otherapp... import...` Another thing to point out is that a "project" is just an "app" with a settings.py file, a media folder, and perhaps a vendor folder. My big thing is that we should drive home the importance of decoupling or loosely coupling your apps. Unless you are 100% certain that you will ALWAYS want to bundle an app with your project AND and that you will NEVER want to use an app without your project, your other apps should exist as separate modules that can be placed anywhere on your python path. If Django were to automatically add the vendor folder to the python path as the second folder (after the folder containing your settings.py file), it would provide a standard way for users to include specific versions of 3rd party apps or their own reusable apps that may or may not be installed elsewhere on the hosting environment. For example, bundling a specific version of Django to be used even if another version of Django is already installed. I've recently decoupled a bunch of apps that were initially too tightly coupled to a common library that I use in most projects. As the apps grew and as we started working on more projects, it became troublesome to have to bundle this increasingly large library of apps when only a handful would be used by a project, and there were also times when I'd have liked to make use of just one in a project that a 3rd party had source code access to without giving them access to everything. I wish that I'd learned sooner to always try and build smaller, simpler apps with more limited and specific scope that were decoupled or more loosely coupled to other apps so that they could be more easily reused. Anything that Django can do to make this point more obvious would be a good thing. Cheers. Tai. On Mar 17, 2:21 pm, Simon Litchfield <si...@s29.com.au> wrote: > On Mar 15, 9:46 am, Russell Keith-Magee <russ...@keith-magee.com> > wrote: > > > On Fri, Mar 11, 2011 at 1:14 PM, Simon Litchfield <si...@s29.com.au> wrote: > > > Who votes we should come up with a django-blessed 'official' default > > > project layout / directory structure? > > > Sure -- no disagreement that it would be good to have some common > > ground with regards to project layout. All we need now is to agree > > what that blessed project layout should be. :-) > > Lowest common denominator is what we're after here I think. Eg -- > > manage.py > --conf > ----settings.py > ----settings_dev.py > --lib > ----other_app1 > ----other_app2 > --my_app1 > --my_app2 > --media > --templates > --templatetags (project tags, non-app specific, if you have any) > --views.py (project views, non-app specific, if you have any) > --urls.py (project urls, non-app specific) > > Or maybe this -- > > manage.py > --conf > ----settings.py > ----settings_dev.py > ----(wsgi files) > --lib > ----other_app1 > ----other_app2 > --project > ----my_app1 > ----my_app2 > ----templatetags (project tags, non-app specific, if you have any) > ----views.py (project views, non-app specific, if you have any) > ----urls.py (project urls, non-app specific) > --media > ----css > ----img > ----js > ----uploads > --templates > > This way we keep our pythons separate from our chickens. > > Also to suggest a preferred media structure or not- at least a > centralised uploads / var media folder would be good practice I think, > at least from provisioning and permissions etc point of view. > > Thoughts? These are just a few suggestions to get the conversation > started! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
