On Dec 28, 2007 5:19 AM, Marinho Brandao <[EMAIL PROTECTED]> wrote: > when I said "a place to put in applications", I did not saying a hard > place to put the applications, but a more flexible way to import them > from. The solution could be a registration (i.e like template tags) by > an kind of interface or common method, or the solution could be > something like django.conf.settings, where from we import settings > that are in the project.settings module but are automatically imported > to django.conf.settings.
This sounds an awful lot like how Django used to work, before magic-removal went through. It would be extremely confusing to many programmers to have an app installed at one location, but imported from somewhere else entirely. Especially since that place ("django.apps" in your example) wouldn't actually contain anything at all. The whole point of magic-removal was to make things like imports behave as straight-forward Python. I don't see any reason to go back now. > I wish to insist that discussion first because I see INSTALLED_APPS > (as it is actually) is a dinossaur in comparison with many adaptable > features of framework (commands, templatetags, backends, serializers, > settings, etc.). INSTALLED_APPS does have its limitations, but I don't think that what you're suggesting addresses any of them. There's an existing ticket[1] which addresses many shortcomings of INSTALLED_APPS, and does so without modifying how apps are actually imported. > We know the best practices, but each programmer has its own "best > practice" when some of us uses "from apps import myapp" some others > simply include the project path to PYTHONPATH, but these practices > turns the code more and more accoupled. Why not import all installed > applications of current project from a once (virtual) package? If you're talking about apps within a project, I really don't think there's much to stand on here. By definition, those apps aren't going to be distributed, so it's only your own code that will have to deal with how they're imported. If you're talking about apps to be distributed, those shouldn't be in the project directory anyway.[2][3] > This could turns the coding more clear, and turns possible more than > one version of same app, an apps repository and apps most independet > that they are. I think an egg package or an app with only .pyc files > that needs to related with others apps but the developer "best > practices" does not are the same "best practices" of another > developer. I don't know about eggs, but there's nothing stopping anyone from having an apps repository, or distributing pyc-only apps in the current system. Also, on the ticket, you said, "Today, the developer must put all of apps in once place, or create symlinks (Windows doesn't supports) or include miriads of paths to PYTHONPATH." Yes, that's true, and I don't see anything wrong with that. True, symlinks and a myriad of additions to PYTHONPATH aren't good solutions, but putting all apps in one place really isn't a bad thing. In my setups, I use c:\django\common on my desktop and /usr/local/lib/django/common on the server, and I just add one entry in PYTHONPATH for the appropriate location. Then I can just drop in as many apps as I'd like in there, and never have to fiddle with it again. They're all also available from all Django projects I might work on, so everything Just Works. Maybe something like that could be a documented "best practice", but there certainly doesn't need to be any code change to make it easy. More to the point, I don't that supporting a magical namespace like "django.apps" would actually solve any of the problems you describe anyway. The INSTALLED_APPS patch[1] does address many of them, but it's completely unrelated to the feature you're requesting. -Gul [1] http://code.djangoproject.com/ticket/3591 [2] http://www.pointy-stick.com/blog/2007/11/09/django-tip-developing-without-projects/ [3] http://www.b-list.org/weblog/2007/nov/09/projects/ --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---