On Jun 16, 8:01 am, Gustavo Narea <m...@gustavonarea.net> wrote: > Hello. > > Russell said: > > > > > > > > It should be easy, specially since you already use WSGI middleware in > > > that server internally (i.e., the AdminMediaHandler). > > > > In runserver.py, you could replace: > > > try: > > > handler = AdminMediaHandler(WSGIHandler(), admin_media_path) > > > > with: > > > wsgi_app_str = getattr(settings, "WSGI_APPLICATION", > > > "django.core.handlers.wsgi.WSGIHandler") > > > wsgi_app = import_object(wsgi_app_str) > > > > try: > > > handler = AdminMediaHandler(wsgi_app, admin_media_path) > > > If this is all we need to do, then why didn't you say so? My > > understanding of your original proposal was that we needed to > > integrate Paste for some reason -- but if we just need to open up a > > configuration point, then I don't have any particular objections. > > Write up a patch, docs and tests and lets get it into trunk. > > That change simply makes using WSGI middleware possible in the development > server. > > > My only caveat on this is that I want to make sure we do it right. > > Graham Dumpleton recently(ish) blogged about Django configuration > > within mod_wsgi [1]. His comments largely concern inconsistencies > > between the development server and deployment. I still need to fully > > digest what he has written; if there's any action required or > > appropriate on our part, I want to make sure we've integrated those > > changes before we start encouraging widespread use of new WSGI > > configuration points. > > > [1]http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html > > Inconsistencies between the development server and production environments > wouldn't be solved with that patch. > > Any Django-agnostic development server, like Paste's, would solve it because > developers will get the same behavior across environments.
Paste has its own problems. Paste server itself does process environment setup that isn't done by other WSGI hosting mechanisms. Specifically, it initialises Python logging in a way suited to Paste based applications. Like with Django development server, you can develop a Paste based application on Paste server which will then not work on other WSGI hosting mechanisms. > This is one of the > reasons why I recommended Paste Script. > > I think Graham is trying to fix a wider problem related to deployment. The > inconsistency issue in particular could be avoided if the development server > didn't perform Django-specific routines at startup which no other WSGI gateway > would do: Not importing any module at startup time; do it lazily instead. There certainly is a larger problem I also want to address beyond pointing out the issues with Django deployment, but I haven't even mentioned them in these posts and don't intend to. What you are trying to do with using Paste Script/Deploy is tinkering at the edges of a larger issue you probably don't even know exists or don't appreciate. Paste Script/Deploy will not solve that larger issue as there are lots of things it doesn't do. Adopting it will only make it harder to solve the real problems later on. Trying to address the bigger issue is going to need some cooperation between all frameworks and hosting solution authors to come up with a consistent way of doing certain stuff. Right now though I don't have time to lay out properly what the issues are or implement a proof of concept which illustrates the direction one could take to solve the problem. It may be the case that Paste Script/Deploy could be adapted to meet that requirement at some point, but by itself, because the focus of Paste Deploy is more about constructing WSGI components together to create an application, as opposed to solving the problem of deployment on a specific hosting mechanism, I feel right now it is a poor choice. If time allows I hope to talk to Russell about some of this stuff when he is at PyCon in Sydney, but it will still need a lot more work after that. Ultimately if something doesn't get done to address the bigger issues, the WSGI deployment (distinct from composing together WSGI components into an application), will continue to be a dogs breakfast. Graham > When called, the "manage" script imports the modules in INSTALLED_APPS to > generate the list of management commands which triggers other actions which > would not happen under other servers. Put simply, running the development > server within the "manage" script is the cause of the inconsistencies. > > The other solution I can think of would be doing exactly the opposite: Make > the WSGIHandler trigger the actions caused by the "manage" script (e.g., > importing all the INSTALLED_APPS at startup time, validate models). > > > > import_object() is a function I just made up; I'm not sure if there's > > > something like that in Django already. We could either implement it on > > > top of importlib or do something different. > > > Django has django.utils.importlib.load_module, which mirrors the > > importlib tools available in Python 2.7. This method is used > > extensively in Django as a way of implementing extensions and backends > > for various features. > > Good, I'll keep that in mind. > > > > I did *not* say Django or the current request objects were "less > > > mature". I called "less mature" any potential *change* *in* *Django* > > > in order to solve problems WebOb already solves. > > > We have two choices here: > > * A small set of (possibly complex) changes to fix bugs in Django's > > request layer. > > * A large set of changes to replace Django's request layer with WebOb. > > > I simply don't accept that (1) is necessarily more complex than (2). > > Replacing core infrastructure is *never* a trivial activity, and in > > this case, replacing a piece of core infrastructure means introducing > > a major dependency into Django as a framework. Simply stating "WebOb > > is better" won't convince me here -- you'll need to demonstrate why. > > From a WSGI/interoperability side of things, it's better because it's > stateless. Every change you make is propagated/applied to the WSGI environ, > not kept to itself. > > As for Django-specific things, I think the HttpRequest object should set > environ['REMOTE_USER'] to request.user.username when request.user is set to an > authenticated user... for example. > > From a broader non-WSGI-specific perspective, WebOb also provides getters and > setters that proxy the environ to many things not covered by > HttpRequest/WSGIRequest in Django: In Django requests, the headers are > available under request.META["HTTP_*"] and their values are *always* > *strings*. WebOb lets you handle then using appropriate Python types; e.g., > the content length is an integer, the Date header is a datetime object. > > Here's the complete list of > getters/setters:http://pythonpaste.org/webob/class-webob.Request.html > and, just in case, here's the source > code:http://bitbucket.org/ianb/webob/src/tip/webob/request.py#cl-88 > > If these reasons are not enough to add WebOb as a dependency, I'm still > willing to provide a patch to at least make WSGIRequest propagate the relevant > changes to the WSGI environ, which is my #1 concern. > > > Ok - at this point, I'm broadly happy with your proposals (subject to > > the caveats I've given along the way). The next step is to show us > > actual code. This won't get applied to trunk as a single monolithic > > "fix WSGI" patch - it needs to be (at least) 4 patches, one for each > > feature that is being added, and each patch will need to be tested > > (and if appropriate, documented). Each of these features should also > > be logged as a ticket (if they aren't already). > > > If you're looking to maximize the likelihood that this will land in > > trunk, the best approach will be to concentrate on one of the four > > issues (preferably starting with a small one), and see it through to > > completion; then move onto the next issue, and so on. > > That sounds good to me. I'll get to work on the patch to make WSGI middleware > possible in the development server. > > > >> I'm also interested how this relates to the work that was done on > > >> Django's WSGI interface during last year's GSoC. Are you at all > > >> familiar with the work on this branch? If so, what is the extent of > > >> the overlap between your code and that branch? > > > > AFAIR, that branch would've solved (3) only. > > > It might only solve (3) from your list, but I'm pretty sure it solves > > a bunch of other issues as well. The final diff for the branch > > contains a lot of code, and theoretically represents 12 weeks of > > full-time work; I may have to try poking Chris Cahoon off-list for a > > description of what is contained in his branch. If there is other ore > > in that branch (and I suspect there is), we should be aiming to mine > > it. > > Yes, it's likely it also does more things. I checked that branch ~7 months > ago. > > Cheers. > -- > Gustavo Narea <xri://=Gustavo>. > | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
