#16360: Add a standard entrypoint for WSGI to project template
------------------------------+------------------------------------
Reporter: jezdez | Owner: nobody
Type: New feature | Status: new
Component: Core (Other) | Version: SVN
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
Comment (by carljm):
Replying to [comment:11 jezdez]:
> > I'd also like to try a more explicit approach to settings, using a
dotted path to the settings module in `wsgi.py` rather than `__name__`
>
> The big advantage for `__name__` is the fact that it allows the wsgi
module to understand how the deployment server imports the file, whether
as `projectname.wsgi` or just `wsgi`. I believe that's not implicit or
magical, just using a Python feature.
Using __name__ isn't adding implicit behavior, that's just a Python
feature as you say. But automatically finding the settings module if its
"next" to wsgi.py, and otherwise requiring DJANGO_SETTINGS_MODULE to be
set, is adding implicit behavior (roughly parallel implicit behavior to
what manage.py already does, but nonetheless spreading it beyond
manage.py).
Anyhow, after our IRC conversation I understand the reasons for this, and
they are understandable, even good reasons. Thanks to the sys.path-munging
in setup_environ, we've long since set up the expectation that we'll set
up sys.path for people (and allow them to import stuff as either
myproject.* or just *). This patch just expands that already-longstanding
magic to cover not only manage.py and runserver but all WSGI deployments,
so people will hit fewer hurdles going from development to production,
which is certainly a good goal.
In the general theme of making Django play nicer as a Python library,
though, I think the sys.path-munging in setup_environ is a real problem,
and I know other people have identified it as one. It causes real-world
issues, like the double-imports issue from overlapping sys.path, and the
problem where people commit their project as top-level in a VCS repo and
then it breaks when checked out under a different name, or a not-valid-
Python-module name. So I would love to take this opportunity to see if we
can fix that in a backwards-compatible way before we expand its reach
beyond manage.py/runserver.
I have some ideas for how we might do that; won't go into it here but I'll
post to the mailing list soon with some working code.
If I don't get to that in time, though, I don't want to hold this up for
it. I think we can still fix it after this has gone in, though it'll be
harder and involve more deprecations.
--
Ticket URL: <https://code.djangoproject.com/ticket/16360#comment:12>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
