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 Tue, 27 May 2014 14:43:48 GMT
On Fri, 2014-05-23 at 11:40 -0400, Justin Ross wrote:
> 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.

If I do tests directly against a build rather than an install, I will
pick up the installed version even if the build is first in PYTHONPATH.
I can set QPID_DISPATCH_HOME in the build env script I just think it is
ugly. I don't have a better solution (yet) given your point about not
putting internals in site-config.

> On Fri, May 23, 2014 at 11:28 AM, Justin Ross <jross@apache.org> 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.
> >
> > 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
> >

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

View raw message