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: [email protected] For additional commands, e-mail: [email protected]
