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
-~----------~----~----~----~------~----~------~--~---
