qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: dispatch: getting rid of QPID_DISPATCH_HOME in python scripts.
Date Mon, 02 Jun 2014 20:42:21 GMT
On Fri, 2014-05-23 at 11:28 -0400, Justin Ross wrote:
> 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.

And how are you going to prevent those irritating users from looking
at /usr/bin/qdstat and observing that it imports all its bits
from /usr/lib/qpid-dispatch/python/blah, and going ahead and using it
anyway? This is python, we can't stop people from using it if they want
to, all we can do is make it clear that we won't support it.
 
IMO if we put this in site-confg/qpid_dispatch/_private/*.py and stick a
"NOT SUPPORTED" comment at the top, that would give us just as much
protection (in terms of making it obvious that we don't intend it to be
public) but avoid the extra env var muck, the ugly cmake substitutions
in our python tools etc.


> Case in point: qpidtoollibs was supposed to be an internal only library for
> use by qpid-tools stuff.  That didn't pan out.

We didn't take 
> 
> 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



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message