On Sat, Aug 15, 2009 at 12:24 PM, Graham
Dumpleton<graham.dumple...@gmail.com> wrote:
> On Aug 15, 1:15 pm, Yuri Baburov <burc...@gmail.com> wrote:
>> Hi all,
>>
>> I'm trying to figure out correct overall and settings path usage
>> strategy for my Django applications.
>> What I am experiencing now is that settings.py is imported 4 times on
>> "python manage.py runserver" command,
>> twice as "settings", and twice as "myapp.settings", given that my
>> project is named "myapp".
>> It also doesn't care if I set DJANGO_SETTINGS_MODULE env option and
>> PYTHONPATH env option.
>>
>> My desire is to make it use "settings", and don't ever use project
>> prefix "myapp."
>
> Personally I believe that eliminating the project prefix is a bad
> idea. By doing that you start to push to much stuff into global module
> namespace and too much change of a conflict.
Maybe let's rename all apps to UUIDs then? :)
I have never experienced namespace conflicts you are talking about.
Chance of conflict is almost zero.
You underestimate python import agility.
Only global modules get into global modules namespace, app modules get
into app namespaces.
Local modules are checked before global ones. If you will load "q"
from "w", it will be imported as "q.w" into sys.modules
Say, realapp1 can have module models.py and can be accessed as
"models" from inside and "realapp1.models" from outside. Local modules
will be checked before global from inside, and no name conflict will
ever arise.
But most times internal "models" are also accessed as
"realapp1.models", of course.
This will work until you will use app as sub-app of some other app
(say, I want to use django-filter as beautils/filter/ and it will not
work because it uses filter.* form of imports). Such reuse will be
possible only with local imports imports.
> What I would suggest is experimenting with standardising on one prefix
> and having everything internally reference via that no matter what the
> project directory is called. You can then set up a dummy module as
> entry point.
It's just very bad idea to have 2 apps with the same name, but single
global namespace won't help it!
Be it project name, or "djangosite".
I also use few more techniques:
I could use "apps/" folder to put my project-specific apps inside if i
wanted to. Apps will get names like "apps.somename". I tried, for IDE
to show in better way, but it wasn't really needed :)
And I symlink apps I need into my project directory.
Typical folder structure in my projects:
~django/ -> ../django-trunk/django
~beautils/ -> ../beautils
realapp1/
templates/
media/
media/~admin/ -> ../django-trunk/django/contrib/admin/media
media/~beautils/ -> ../beautils/media/beautils
media/~realapp1/ -> ../realapp1/media
settings.py
urls.py
I include only apps i needed, maybe that's the reason I don't
experience conflicts.
Two conflicts I've got within a year of work with django were "blog"
app with "blog" project and "utils" app with "utils" module, because I
left utils.pyc when removed utils.py. I can do nothing with second,
but first required a hour to find, and not only me, but my friend once
also get the exactly same problem and would also spent a lot of time
to find it if he didn't ask me :)
Will manage.py startapp raise an error if a project has the same name
as application? Will python manage.py validate do so?
And installing django modules into python environment I believe is a bad thing,
mainly because different projects might use different versions of applications.
I apply the following general rule here:
You should be able to update a library or application in one project,
not breaking others.
>> Because this will cause much greater app reusability in different
>> projects, because of "blog" project and "blog" application possible
>> import clashes (and weird errors from urlconf loader), because I want
>> to be able to rename project at any moment, because i want "111" or
>> "project-v1.1" to be also correct project folders. This is my general
>> rule: my apps shouldn't start with project prefix.
>
> So for your example, do the following:
>
> import imp
> import sys
> import os
>
> djangosite = imp.new_module('djangosite')
> djangosite.__path__ = [ '/some/path/projects/projects-v1.1' ]
> djangosite.__file__ = '/some/path/projects/projects-v1.1/
> __init__.py'
>
> sys.modules['djangosite'] = djangosite
>
> os.environ['DJANGO_SETTINGS_MODULE'] = 'djangosite.settings'
>
> Doing this also means you do not even need the parent projects
> directory in sys.path, which is effectively what runserver does as it
> adds it only long enough to import the __init__.py file as package
> root and then removes the directory.
>
> Anyway, within urls.py and all your code you could then always perform
> import references as 'djangosite.etc.etc'. With it standardised, then
> quite easy to move stuff between site implementations or rename site
> directory and not have to change everything in it.
And as I explained above, this is not better than "etc.etc"...
I wish "etc.etc" be standardised :)
And everything will work even for "project-v1.1" without any dummy packages.
> This does mean that __init__.py in root of Django site package should
> always be empty, but normally it is anyway.
Well, I don't find any reasons to put anything there.
You have settings.py and urls.py for that, and they can be reloaded
easily if needed.
It's like "we allow you to make your life more painful, that's why
__init__.py is there".
But I don't have any problems with it, so let __init__.py be.
> Another thing to consider is creating another dummy module entry point
> for a directory holding all your reusable applications. This one could
> be called 'djangoapps' with references always made via that path.
All my applications are "reusable", but not all will be ever reused.
So I don't understand why I need this folder. I can create a folder
"djangoapps" instead of the dummy module, if I need to.
But why should I?
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
