On Thu, Mar 17, 2011 at 9:26 PM, Calvin Spealman <ironfro...@gmail.com>wrote:
> -1 On django manipulating PYTHONPATH +1 On encouraging people to keep their applications out of their project! > I think, it's a good idea to add new option to startapp command for create Django application out the project and has structure compatible with setuptools and distutils: django-my-app/ --setup.py --README.txt --doc/ ----... --my_app/ ----models.py ----views.py ----urls.py > 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. > -- Alex Kamedov skype: kamedov www: kamedov.ru -- 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.
