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/
pgpODesafkFhh.pgp
Description: PGP signature
