On Thu, Mar 17, 2011 at 5: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...`
I strongly disagree here. Django shouldn't be doing magic with my PYTHONPATH, if I want stuff in my PYTHONPATH, I'll darn well put it there. > > 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. No, not really. Projects don't have models, for a start. > > 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. This issue is well solved in the python world. It's called virtualenv. Django should not be replacing standard python processes with Django magic. > > 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. > Yep, that is particularly important when writing re-usable code. It's not just true of 'apps', but also of python libraries, which a django app is a particular example of. Cheers Tom -- 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.
