Thanks for the responses! I wasn't aware of that environment variable
which seems like an excellent solution.

I ended up experimenting with something else (before finding out
about that) that seems to work and even allows me to use a single
qp_sites dir. Based on your blog post about qp and Python 2.5
appearing to work well together, I upgraded to Python 2.5 and changed
all of my "from qp.sites.xxx.yyy import ..." statements to the new
relative import syntax: "from .yyy import ...". This removed all
references to the site name from my qp code and allows it to run
unmodified in three different site directories: xxx_production,
xxx_test, and xxx_dev.

I then added code like the following to my SitePublisher class:

     configuration = dict(
         https_address=('', 443),
         )

     for mode, mode_conf in (("_production/", dict(scgi_address=
('localhost', 9000),
                                                   durus_address=
('localhost', 7000))),
                             ("_test/", dict(scgi_address=
('localhost', 9001),
                                             durus_address=
('localhost', 7001))),
                             ("_dev/", dict(scgi_address=
('localhost', 9002),
                                            durus_address=
('localhost', 7002)))):
         if mode in __file__:
             configuration.update(mode_conf)
             break
     else:
         raise Exception("cannot determine site run mode")

I could move to a non-source code controlled file for this as you
suggest, but I like having it all in one place and under source code
control.

I have my business logic in another non-qp package which also has
production, test and dev installations. I don't allow the business
logic to refer to anything in my site code so all I need is this at
the top of slash.qpy:

for mode in ("_production/", "_staging/", "_dev/"):
     if mode in __file__:
         sys.path.append("/home/qpuser/zzzpkg" + mode)
         break
else:
     raise Exception("cannot determine site run mode")

While that package selection code doesn't work quite right when the
qp command instantiates multiple sites, it works fine on operations
that involve one site at a time.

Dave

------
David K. Hess
Verscend Technologies, Inc.
dhess@verscend.com
214-684-5448



On Dec 2, 2006, at 7:45 PM, Michael Watkins wrote:

> * 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
>         ...
>
> _______________________________________________
> QP mailing list
> QP@mems-exchange.org
> http://mail.mems-exchange.org/mailman/listinfo/qp