-1 On django manipulating PYTHONPATH +1 On encouraging people to keep their applications out of their project!
On Thu, Mar 17, 2011 at 1:08 AM, Tai Lee <real.hu...@mrmachine.net> wrote: > 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. > > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy -- 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.
