* David K. Hess wrote [2006-12-02 08:52:44 -0600]:
> Does anyone have some best practices they can share on how best to use the
> same qp code base in both a production and test site sitting side by side
> in qp_sites?

Currently I have different physical environments for dev, test and production
so my qp.sites looks the same.

In the past I have used alternate login id's on my dev machine to set up
"test", the same on a production machine for "staging". The alternate ID's
have their own customized Python environment. As of the last significant
revision of QP the use of environment variables makes all that much easier on
the same box when necessary.

> The biggest issue of course is import qp.sites.xxx statements scattered all

As noted, this is less of an issue now, but I still use every occasion
when I type `from qp.sites.foo import ...` to think whether the object being
imported belongs in the app or a library.

PS, I keep `configuration` in a module which isn't managed by version control
*directly* and import it. Makes it easy to have dev, test, staging and
production 'configurations' without altering slash.(py|qpy).

    class SitePublisher(DurusPublisher):
        from qp.sites.foo.config import configuration
        ...