On Sat, Aug 15, 2009 at 4:48 PM, Graham Dumpleton<[email protected]> wrote: > On Aug 15, 6:42 pm, Yuri Baburov <[email protected]> wrote: >> On Sat, Aug 15, 2009 at 12:24 PM, Graham >> Dumpleton<[email protected]> wrote: >> > On Aug 15, 1:15 pm, Yuri Baburov <[email protected]> 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. > > You underestimate stupid users. I have seen many times where users > stuff up because they do something like call a script file django.py > or test.py and wander why the latter standard packages/modules of same > name can't seem to be found, or why their own code isn't found. There > are lots of other standard modules in Python which one can conflict > with as well because of use of quite generic names. I'm trying not to underestimate stupid users. But we are currently have nothing to help those users, while we are able to. Does anyone need to have twice imports? I guess no. We can write a tool which will look and raise exception if any module was just imported twice. I can. This is 15 minutes work thanks to PEP-302. We can install it into runserver and maybe some other command, maybe add into testing and it will yield on import-twice sort of errors. Of course, it's not very good idea from "idealistic" point of view, but for stupid reality, it's the best solution I can come with. It will work. Don't be afraid to hurt users feelings in the situations users would say thanks to you if they knew what you have done. I'm saying thanks to every django contributor, but I'm not going to say thanks to anyone who did this import "projectname.module" cause I just see better solution.
>> Only global modules get into global modules namespace, app modules get >> into app namespaces. > > You said that your 'desire is to make it use "settings" , and don't > ever use project prefix "myapp."'. To do that, it means that > 'settings' has been promoted to global modules namespace. > > Django runserver is a pain in that it effectively allows this by > default, and in part why you are seeing the problem you are having in > the first place. > > That is, it may add sys.path temporarily to import site package root > into sys.modules so that 'site.settings' works, but the current > working directory of the runserver is the actual site directory. This > means importing 'settings' works as well. That is, 'settings.py' is > importable as both sub module of site package, but as global module in > it is own right. Thus why it can be imported twice. If the runserver > had been implemented to change to a different directory, it would get > rid of this problem and also get rid of the problem where people use > relative path names for stuff which may work for runserver but then > doesn't work when they move to hosting with mod_python, mod_wsgi, or > fastcgi. Hold a second. Nobody's telling manage.py that was created by django-trunk with django-admin.py startproject xxx to do dumb "import settings". Just tested again to be sure. Nobody's telling django.core.management.setup_environ to set DJANGO_SETTINGS_MODULE to 'xxx.settings' and do "import xxx.settings" later. This behavior is a bug. Current django is forcing importing that twice. Do you agree? I will file bug report then. Figuring out now what's better solution. >get rid of the problem where people use relative path names for stuff... I was using fastcgi, fastcgi+flup, scgi, mod_python, mod_wsgi. I haven't experienced problems with relative path names except for that blog/apps/blog/. Maybe I just don't get you now. Relative path names are not evil. Having incorrect setup instructions, having chance to suffer from wrong imports but not validate them, and telling relative paths causes that is evil. My friend from byteflow blog project have done a management command that's telling setup instructions for your web server. If any user was using them, no problem with paths should ever arise. Everyone's happy. >> 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. >> 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". > > You possibly don't fully understand why I am suggesting this and how > it would be of use. Maybe the problem is that you are after something > other than the problem I perceive you are trying to solve. You perhaps > also haven't encountered as many times the issues around this double > import and fact that imports can be done without listing site package > root at same time as I have in answering Django questions on the lists > over the years. It is one part of Django I would really like to have > seen be done differently because of the grief it keeps causing people > who want to host with mod_python and mod_wsgi. > > FWIW, having all sites use the same logical package root name wouldn't > cause any harm because for Django, it is impossible to host multiple > Django site instances within the same Python interpreter. Thus there > can be no conflict. Some other Python web frameworks also get away > with always effectively having site package root be same name, because > they, like Django can only have one instance in a Python interpreter. > Thus the concept works albeit the means they do it may be different. > > One of the problems it would solve is where people leave off the site > package root name because they want the ability to easily copy view > code or other stuff from one Django site to another without having to > change imports within that code. Because runserver current working > directory isn't changed, they unfortunately have the back door, as > they can leave off the site package root name from imports and they > will allow them to migrate code as they want. As explained though, > that results in multiples ways to import the code, ie., problem isn't > just with 'settings.py' but any code within a site. Result is you > sometimes see people having problems with code working strangely and > that is because of double imports of their code. If I do "import settings" and django does "import djangosite.settings" is this a problem with my code actually? > Anyway, rather than going the direction of aliasing the package name > for site root, you want to get rid of it entirely, meaning that > everything in the site directory in effect is a global module/package > scope. The problem is not that some user package will go into global module/package scope. Python builtin and system-wide installed modules get into that scope. Do you believe that is also a problem? I see the problem that namespaces clash could happen and user to be unaware. That's why users shouldn't be able to create such project names or create with care, that's why management commands should raise warnings or errors, depending of the command. Like, manage.py startapp shall raise an error that the name is name of standard module in pythonpath. manage.py validate (and so runserver which runs validate first) shall check that, raising a notice, which can be suppressed. By the way, there were attempts to improve startapp. Don't remember the state of that patch. The problems of twice-imports and cluttering root module scope shall be properly documented if it causes any recurring troubles, more wise users will be able to point there those unwise, error shall point to the related doc page. This is systemic approach to fix problem. Telling that you have to explain to users again and again that they might have wrong imports (and this is the best you can ever do) is not systemic approach. I explained them the situation too, but I believe now is the moment quantity should be converted into quality. I can volunteer for docs, but I'd like to force my code ideas to production then. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
