Re: dispatch: getting rid of QPID_DISPATCH_HOME in python scripts.

[Alan Conway <ac...@redhat.com>]

On Fri, 2014-05-23 at 11:28 -0400, Justin Ross wrote:
> On Fri, May 23, 2014 at 11:16 AM, Alan Conway <ac...@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

Re: dispatch: getting rid of QPID_DISPATCH_HOME in python scripts.

[Alan Conway <ac...@redhat.com>]

On Mon, 2014-06-02 at 16:55 -0400, Darryl L. Pierce wrote:
> On Mon, Jun 02, 2014 at 04:42:21PM -0400, Alan Conway wrote:
> > 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.
> 
> I would disagree, since by putting them into the site-packages hierarchy
> we're implying that they're public APIs, or implementation details for
> _some_ public API set.
> 
> This is a pattern that several other projects use as well for
> internal-only Python libraries, to put them into a directory under lib
> named for the project.
> 

OK, I give in!


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

Re: dispatch: getting rid of QPID_DISPATCH_HOME in python scripts.

["Darryl L. Pierce" <dp...@redhat.com>]

On Mon, Jun 02, 2014 at 04:42:21PM -0400, Alan Conway wrote:
> 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.

I would disagree, since by putting them into the site-packages hierarchy
we're implying that they're public APIs, or implementation details for
_some_ public API set.

This is a pattern that several other projects use as well for
internal-only Python libraries, to put them into a directory under lib
named for the project.

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/