On Wed, Jul 10, 2013 at 09:23:01PM +0100, Gordon Sim wrote: > Right now the python-qpid fedora package, to use a concrete example, > installs into sitepackages (qpid/messaging.py etc). Are you > proposing to change that?
No, I think I've combined how Ruby and Python work in this case. With Ruby gems you can have multiple versions of a gem installed and require only the version you need in your app. When skimming over the Python docs on eggs I mistook some of what it said in there as being the equivalent to what Ruby can do. > >Not so much nicer as more consistent across the supported set of > >languages. In Ruby we have Qpid::Messaging, in Perl it's > >qpid::messaging, in C++ it's qpid::messaging. It would be nice to have > >Python also be qpid.messaging > > It is! And has been long before the Ruby or Perl equivalents even existed. > > The issue is that we now have two *different* messaging libraries > for python... > > >and not something different, to keep it as > >intuitive as possible. > > ... I think trying to force the two into the same namespace is far > from intuitive. I think your previous suggestion to have a compatibility import might be the better way to go. How about something like this: 1. move the pure Python bindings to the qpid.pure package 2. leave the Swig bindings in cqpid for the time being 3. create a new module that lives in qpid.messaging and which will import either qpid.pure or cqpid depending on a setting from the application importing them? This, I think, comes close to what you were proposing. -- 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/
pgpzF9vh4ovj8.pgp
Description: PGP signature
