In which scenarios are you having to set it? If you produce two builds to two distinct install prefixes, they should be pre-defaulted with the approprate home dir, so you shouldn't have to set it.
On Fri, May 23, 2014 at 11:28 AM, Justin Ross <[email protected]> wrote: > On Fri, May 23, 2014 at 11:16 AM, Alan Conway <[email protected]> wrote: > >> Scripts like qdstat currently load the qpid_python_internal module in a >> special way by using the value of the env. var QPID_DISPATCH_HOME. This >> is very weird and surprising. It creates havoc if you have multiple >> installs or builds of dispatch and assume that you just need to set >> PYTHONPATH to make things work. >> >> The normal way to locate python modules is via PYTHONPATH. I propose we >> treat qpid_python_internal like any other python module, install it in >> the standard place by default and let users just set PYTHONPATH to pick >> up all the python bits they need. I don't see any reason why it needs >> special treatment. The name makes it pretty obvious that it is an >> internal module and not for general use (maybe _private would be >> clearer?) >> >> Any objections? >> > > Yeah, from me! I consider using site packages for private python > implementation details a seriously bad idea. People *will* start to use it > if it suits them, and then we *will* change our behavior to support those > unintended users. That's not we want for these implementation details. > > Case in point: qpidtoollibs was supposed to be an internal only library > for use by qpid-tools stuff. That didn't pan out. > > Setting a home var for distinct instances is not burdensome, IMO. It will > likely end up being used for other static resources, as many programs do, > and then you will need a home var for running multiple instances anyhow. > > So bottom line for me: site-packages is not for private stuff. > > Justin >
