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
