with the version below. As you say its not obvious to newbies, but the
two things I do like about it are:
1) It "enforces" putting the wsgi file in a sub-directory. Since its
assuming the sub directory in use it will bomb without it. Probably
not the most elegant approach, but should prevent folks from dropping
the WSGI into the project root. It will make the name of the sub
folder irrelevant (except in the apache config of course)
2) It removes all hard-coded references. This should allow any of our
developers to copy/paste this file into their project and run it on
our apache server without needing to make any modifications,
regardless of their development configuration.
import os
import sys
project_folder = os.path.dirname(os.path.dirname(__file__))
project_name = os.path.basename(project_folder)
project_parent_folder = os.path.dirname(project_folder)
sys.path.append(project_parent_folder)
settings_module = project_name + ".settings"
os.environ['DJANGO_SETTINGS_MODULE'] = settings_module
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
Also, I appreciate the the speed and completeness of your responses.
Its nice having the dialog while things are still fresh on the
brain :)
On Sep 5, 8:11 pm, Graham Dumpleton <graham.dumpleton@gmail.com>
wrote:
> I don't disagree that calculating paths based off __file__ in some
> way, where WSGI script is contained somewhere within the Django
> project, is a good idea. The problem is that the majority of newbies
> wouldn't understand what that non obvious bit of code is actually
> doing. Thus as far as supporting newbies, using explicit paths is just
> easier, especially where ultimately you have no control over where the
> WSGI script file is put, with many people not noticing, or simply
> ignoring that it be put in a specific place such as the 'apache' sub
> directory mentioned.
>
> If the WSGI script file were auto generated as part of the project and
> included documentation in it explaining what each bit does, then that
> possibly would be best way of doing it. Right now though, there are
> still questions marks in my mind that the offered WSGI script file
> recipe is even correct, given that it sets up an environment different
> to what happens with runserver as explained in that blog post I
> referenced.
>
> Graham
>
> On Sep 6, 9:44 am, DaveP <davidpet...@gmail.com> wrote:
>
>
>
> > Thanks Graham, It kind of felt that os.path.dirname & os.path.basename
> > were accomplishing the same thing as using the split, I didn't realize
> > one was better than the other, thanks for calling that out.
>
> > I had glazed over dropping the WSGI file into the Apache subfolder, so
> > thanks also for pointing that out.
>
> > My original concern still exists however. Hard coding these settings
> > is a nightmare. Please keep in mind I come from an operational
> > background not a development background, so many of the finer points
> > of the underlying mechanics will be out of my initial understanding of
> > Python. That said, one of the biggest grips operations folks have is
> > when developers are developing their applications on whatever dev
> > platform they are on, and then when they request a promotion to
> > production, a series of configuration (in this case code) changes are
> > required to get it to run.
>
> > The easy answer is of course to say "develop on a system similar to
> > production" which of course no one will say is a bad idea, however
> > given the simplicity of this file, it seems a "standard" location for
> > the WSGI within the hierarchy of the project could be
> > established,i.e. /apache/django.wsgi, as is indicated in the
> > documentation, and as such all hard references removed from the file.
>
> > I totally get WHY the hard coding can be used, and its great that is
> > flexible enough to allow for it, but if the documentation were to
> > steer folks to a standard and removing such hard coded entries, it
> > would be nice.
>
> > After recently going through an exercise of promoting someone's
> > project to production, it was far more painful that it should have
> > been. I think someone with the right level of Python experience should
> > be able to work up an example that does not require hard coding this
> > information.
>
> > Thanks for taking the time to comment on this. As I've been learning
> > more about Python and Django, I am liking it, but it needs some work
> > on the "getting it out of development and into production front"
>
> > Thanks Again.
>
> > On Sep 5, 7:05 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> > wrote:
>
> > > On Sep 6, 5:01 am, DaveP <davidpet...@gmail.com> wrote:
>
> > > > Let me first state, I'm fairly new to Python and even newer to Django,
> > > > so if what I'm mentioning is already an ongoing effort, I apologize.
>
> > > > I was reviewing the following documentation:http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/.
>
> > > > I has a question/possible suggestion. The documentation suggests that
> > > > you should place your wsgi file in your project, which I think is a
> > > > very valid location for it.
>
> > > No it isn't and the documentation of the mod_wsgi site warns against
> > > doing that. Instead it says to create a subdirectory called Apache and
> > > place it in that.
>
> > > This is because you need to tell Apache that it is allowed to serve up
> > > files from that directory. If you put the WSGI script file in the same
> > > directory as the settings file, then you consequently could be saying
> > > that Apache can server up all your site source code, including your
> > > settings file with passwords in it.
>
> > > The only saving grace is that for files to be accessible requires two
> > > steps. The first is saying that Apache can serve up files from a
> > > directory. The second is there being a URL mapping in Apache which
> > > exposes that directory under some URL. Normally the latter isn't going
> > > to exist unless Apache configuration stuffed up, by why reduce your
> > > security and make it that bit easier to expose your code when you do
> > > muck up the Apache configuration.
>
> > > > My question and potential suggestion
> > > > stems from the contents of the file itself.
>
> > > > This line sort of bothers me: sys.path.append('/usr/local/django'). As
> > > > well as the statement:
> > > > "Remember to replace 'mysite.settings' with your correct settings
> > > > file, and '/usr/local/django' with your own project's location."
>
> > > > Doing that makes the project less portable, and requires changes from
> > > > environment to environment. This is obviously not a difficult thing to
> > > > accomplish, however I think the wsgi file could be made a little more
> > > > generic and accomplish the task at hand.
>
> > > > So on the surface it would appear the recommended wsgi file should
> > > > look something like (obvious path variations):
>
> > > > # Start Example From Documentation
> > > > import os
> > > > import sys
>
> > > > os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
>
> > > > sys.path.append('/usr/local/django')
> > > > import django.core.handlers.wsgi
> > > > application = django.core.handlers.wsgi.WSGIHandler()
> > > > #End Example From Documentation
>
> > > > I think this could be simplified and made more portable for everyone
> > > > with something more like the following. I intentionally used a few
> > > > extra lines for readability, but it could of course be consolidated to
> > > > use less variables
> > > > #Start Sample of Suggested Alteration
> > > > import os
> > > > import sys
>
> > > > project_folder = os.path.split(__file__)[0]
>
> > > Go read what os.path.dirname() does. It is a better way of doing what
> > > you are doing.
>
> > > > project_parent_folder = os.path.split(project_folder)[0]
> > > > project_name = os.path.split(project_folder)[1]
> > > > sys.path.append(project_parent_folder)
> > > > settings_module = project_name + ".settings"
>
> > > > os.environ['DJANGO_SETTINGS_MODULE'] = settings_module
>
> > > > import django.core.handlers.wsgi
> > > > application = django.core.handlers.wsgi.WSGIHandler()
> > > > #End Sample of Suggested Alteration
>
> > > > This version doesn't require any changes from project to project, and
> > > > is independent of where the project is stored. This should lend itself
> > > > to promoting projects from development into production where directory
> > > > layouts may differ.
>
> > > > I had also thought that perhaps the wsgi file could be auto-generated
> > > > from the django-admin.py startproject command. I can can certainly
> > > > understand if the desire is to minimize the amount of files created as
> > > > part of the startproject command, however at the very least, I think
> > > > updating the documentation mentioned above, would be beneficial.
>
> > > > Again, I'm pretty new to all this stuff, so If I've missed something
> > > > or what I'm suggesting is just dumb, please don't be afraid to let me
> > > > know that :)
>
> > > Also suggest you go have a read of:
>
> > > http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
> > > http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
>
> > > Graham
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment