qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <jr...@apache.org>
Subject Re: dispatch: getting rid of QPID_DISPATCH_HOME in python scripts.
Date Fri, 23 May 2014 15:28:24 GMT
On Fri, May 23, 2014 at 11:16 AM, Alan Conway <aconway@redhat.com> 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message