On 07/10/2013 06:24 PM, Darryl L. Pierce wrote:
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.
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?
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.
Those statements go in the application code? If so how is that better
than simply importing from one or the other namespace?
Is package_resource not a distribution/deployment tool rather than
something applications would directly invoke in their code?
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.
I don't really understand what you wrote above.
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
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
