On Wed, Jul 10, 2013 at 05:59:43PM +0100, Gordon Sim wrote: > On 07/10/2013 04:51 PM, Darryl L. Pierce wrote: > >On Wed, Jul 10, 2013 at 03:54:44PM +0100, Gordon Sim wrote: > >>On 07/10/2013 01:45 PM, Darryl L. Pierce wrote: > >>>On Tue, Jul 09, 2013 at 04:01:02PM -0400, Ted Ross wrote: > >>>>I would think that downstream repos would package one or the other > >>>>but not both. It would be nice if downstream, it was called > >>>>qpid.messagingregardless of the implementation used. > >>> > >>>Agreed. > >> > >>I disagree. I can see cases where it would be beneficial to have > >>both installed. E.g. you have existing applications that you don't > >>want to switch (if it ain't broke etc), but you also want to try 1.0 > >>(or just the c++ impl) for some new use cases. > > > >I can see someone wanting to try out 1.0, but they'll still eventually > >have to make a decision, right? > > The point is that the decision taken for one use case shouldn't > necessarily force the same choice across the board.
+1
> >Regarding not wanting to refactor existing apps that work, etc., that
> >can be handled by the administrators by putting the old Python bindings
> >in a separate location from the newer bindings by naming the eggs
> >differently; i.e., python-qpid is the old API set while
> >python-qpid_messaging is the newer set. Using pkg_resources the app
> >developer can have both APIs living on the same machine, using the same
> >packages, without collision.
>
> I think its important to keep the different notions of package
> separate. On the one hand there is the python namespace. On the
> other hand there is the platform specific installation approach in
> use (e.g. rpms or whatever).
>
> In the case of the latter, I think it is decidedly odd to e.g. yum
> install python-qpid, yum install python-qpid_messaging and have the
> installation of the second package overwrite artefacts of the first
> one (even assuming this doesn't totally break things).
That wouldn't be the case given that the two can be installed using
separate names, both for the RPM itself also the underlying egg file
shared via other Python methods. The was the collision avoidance I was
talking about above; i.e., installing python-qpid (which ships the qpid
egg's contents) would live in directories named python-qpid-VEV, while
installing python-qpid_messaging (whose foundation is a different egg
named qpid_messaging) would live in directories named
python-qpid_messaging-VER. Both very sheltered from each other.
The app developer can then use something similar to your suggestion
about conditional imports and, instead of catching a raised exception to
pick a different package, could use:
pkg_resource.require("qpid==VER")
or:
pkg_resource.require("qpid_messaging=VER")
to import the desired implementation of qpid.messaging to get the APIs
they want.
> >>>I think it ought to be a goal to have the Swigged bindings be a
> >>>drop-in replacement for the pure Python bindings. The users shouldn't care
> >>>which implementation they use.
> >>
> >>Some won't, some will.
> >>
> >>Though the APIs are getting very close, there are still - and I
> >>believe will always be - behavioural differences. Even apart from
> >>those, we have had users using eventlet and monkey-patching and they
> >>are going to care which implementation they have.
> >
> >I'm not sure how to respond to that. The behavioral differences will
> >result in large differences in how the APIs are expected to work?
>
> There are differences, and those differences could mean that an
> application that works with one does not work with the other.
>
> To state the obvious, the swigged implementation is a different
> library offering (broadly) the same API. It is not an evolution of
> the existing implementation.
>
> It is clearer to give these two different implementations two
> different names.
>
> I can certainly also see cases where users don't want to explicitly
> choose one or the other and want their code to run against either
> without change (I have that need myself as explained in an earlier
> mail). However I think that can be done by a simple (5 line) module
> with a third name.
>
> That way users can pick one, or the other, or explicitly decide they
> don't care and want to pick whichever is available based on path.
Understood. See what I wrote above as another way of approaching this.
> >My main issue is looking at the pure Python bindings and limiting what
> >feels, to me at least, the package name for the swigged bindings due to
> >that. I think we can overcome that without having extra packages on top
> >of them.
>
> I don't really understand what you are saying here. Are you saying
> you want the name qpid.messaging for the swigged implementation
> because it's a nicer name than alternatives?
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 and not something different, to keep it as
intuitive as possible.
And it _is_ a nicer name. Just not primarily that as my reasoning. :D
--
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/
pgpApKF2TtvyX.pgp
Description: PGP signature
