On Sun, Sep 20, 2009 at 6:46 PM, Hostile Fork <hostilef...@gmail.com> wrote: > > Hello all, > > Page one of the tutorial features a large picture of a lightbulb, next > to a statement of Philosophy: > > "Django apps are 'pluggable': You can use an app in multiple > projects, and you can distribute apps, because they don't have to be > tied to a given Django installation." > > The tutorial proceeds to import "mysite.polls.models" from various > files inside the /polls directory: > > > http://docs.djangoproject.com/en/dev/intro/tutorial02/#make-the-poll-app-modifiable-in-the-admin > > http://docs.djangoproject.com/en/dev/intro/tutorial03/#write-views-that-actually-do-something > > I think I'm stating the obvious: if your project is called "mysite" > and your app is called "polls", there should be no appearances of the > string "mysite" inside your /mysite/polls directory. That won't let > polls plug very well into "yoursite". I know changing your PythonPath > can get you to the point where you can say "import polls.models", but > this seems too foundational for the tutorial to gloss over. > > From my point of view, it's a further problem that "polls" appears > inside the app... over and over. Namespaces seem to have been > introduced to work around the inevitable problem of wanting to > instantiate an app twice. But I'd like to have differently-versioned > enlistments of the same app (in different directories) running at the > same time. Can namespaces help me, in a way that I don't have to > "import polls_alpha.models" in /polls_alpha and "import > polls_beta.models" in /polls_beta?? > > (I don't know much Python, but I wish there'd been some way to apply > the DRY principle to my app's name through "sys.modules[globals() > ['__name__']]"...or some other magic). > > What I'd really like to find are best-practices of how to scope > references at every level in the proejct. Right now I find myself in > constant puzzlement. Like, if your PythonPath is going to get you > access to polls.models from inside the mysite directory... why would > your mysite's settings.py refer to it as "mysite.polls.models" and not > just "polls.models"? > > Thanks, > Brian
I've been using os.path based manipulations of __file__ in settings.py to calculate "PROJECT_NAME", which can then be obtained from django.conf.settings and used to customize various strings, even passed in template context. That's less help with bare imports, though you can call the underlying mechanisms to pass the module name as a string (django does this a lot). An alternative, if you are willing to tie yourself to reasonably recent pythons is to use the new explicit relative import syntax. I'm not sure when it changes to the default, probably 2.7?, but you will probably need to use: from __future__ import absolute_inport Then you can say things like: from . import models or from .models import MyModel or, from your templatetags directory from ..models import MyModel Note that this makes it possible to have an app specific settings module, in the same directory as models.py, which can calculate APP_NAME, or the like, and be relatively imported (django.conf doesn't help you here). You can almost do it without absolute_import, since a bare: import settings will get the app specific one from your models.py, views.py, etc., and it will work, but not from subpackages like templatetags. Of course, each module could perform it's own os.path manipulations to figure out the app name. These os.path manipulations probably mean that you can't run from a zipped egg. Bill --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
