settings

On Fri, 2006-09-29 at 02:24 +0100, Henrik Vendelbo - Fashion
Content
wrote:
> Ouch 20 mins into trying out Django and the water is
getting too hot.
> 
> Where am I supposed to put my things such as
mysite.settings?
> 
> I run on FC5 and installed the Django egg. I thought it
would be a good idea
> to put all my stuff in /opt/test-site, but
> apparently I can't use absolute path when referring to
the settings file in
> mod_python config.

The settings config string is treated as a Python module to
be imported.
So you write it in import style (foo.bar.baz.settings) and
it needs to
be somewhere on your Python path. You can put it anywhere
you like and
have your Python path set appropriately.

The "traditional" approach (not a huge tradition,
but such as it is) is
to put the settings file for a project either in the
top-level project
directory or in the directory just above it. That way you
can set your
Python path to the project directory's parent directory and
things seem
"neat". But other setups work, too.

> So I tried to drop the setting sile in site-packages,
but that doesn't seem
> to work either.

Urgh. It's not really going to be a systems-wide settings
file. More
project-wide. So when you come to do project #2, this is
going to have
problems.

> 
> On a side not, why can't django detect that I have
modified a file and
> reload it, much better than running in a beta mode.

Not entirely sure what you mean here. The development server
can detect
this. You can configure mod-python to do so, too, although
it's not
recommended.

The downside of continually watching for changes is the need
to monitor
*every* *single* *file* for changes, which is very difficult
to do in an
efficient and portable fashion. In production situations
(which are the
majority of the use, unless you have no audience at all),
files hardly
ever change, so the default setting for things like
mod-python is
sensible: the developer or systems operators will know when
files have
changed (because they just rolled out new ones) and will
know to reload
the appropriate processes.

Regards,
Malcolm


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---

Malcolm Tredinnick wrote:
> > On a side not, why can't django detect that I have
modified a file and
> > reload it, much better than running in a beta
mode.
>
> Not entirely sure what you mean here. The development
server can detect
> this. You can configure mod-python to do so, too,
although it's not
> recommended.
>
> The downside of continually watching for changes is the
need to monitor
> *every* *single* *file* for changes, which is very
difficult to do in an
> efficient and portable fashion. In production
situations (which are the
> majority of the use, unless you have no audience at
all), files hardly
> ever change, so the default setting for things like
mod-python is
> sensible: the developer or systems operators will know
when files have
> changed (because they just rolled out new ones) and
will know to reload
> the appropriate processes.

The default setting for mod_python is actually to reload
modules. That
this is
the case though is irrelevant anyway as Django doesn't use
mod_python's
module
importer anyway for any code managed under Django. Instead,
Django uses
__import__ directly to import modules. To get this to work
without
naming
collisions Django requires code to effectively reside in one
big Python
package
structure. That it uses a package structure in this way
makes it
basically
impossible to implement a module reloading scheme, as the
very way that
imports within a package are done via the root of the
package causes
loops
in the dependencies between modules within the package.
Because it
isn't
just a tree like structure, the only option would be to
reload every
module within
the package when any single module has changed and even then
depending
on how data is cached and shared amongst modules in the
package, it is
still
not practical and would cause lots of problems.

Even with mod_python there are lots of issues with its
module importer.
These
have been documented at:


http://www.dscpl.com.au/wiki/ModPython/Ar
ticles/ModuleImportingIsBroken

A new module importer implementation in mod_python 3.3 will
fix just
about
all of the issues, but in doing so it explicitly ignores
Python
packages and
will not consider them as something that can be reloaded.
Because of
how
Django relies on Python packages, it wouldn't even be able
to use a
similar
scheme. To do so would require a fundamental part of how
Django works
to
be changed and there is no way people would accept that.
Thus, because
of
that earlier design decision, I would suggest you will never
see
automatic
module reloading in Django.

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-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at http://gr
oups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---