On 07/10/2013 12:25 PM, Gordon Sim wrote:
I have been working to get (at least some of) the python tests running
over the swigged implementation. My motivation here was initially to add
some new tests for the AMQP 1.0 functionality using python. However it
would also be desirable to be able to ru
On 07/10/2013 10:47 PM, Darryl L. Pierce wrote:
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
I think we should leave the existing pure python client as it
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 ge
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
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 wou
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.
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
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.
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 think it ought to be a goal to have the Swi
On 07/09/2013 08:34 PM, Darryl L. Pierce wrote:
One of the issues that needs to be fixed for this is the package name
for the code. Currently it's "cqpid", which isn't close to what we have
in other languages (which all use a variable on qpid.messaging).
However, we can't use that since it's wha
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. Is there a way to
parameterize it such that the namespace could be overridden when built
and packaged?
For exam
One of the issues that needs to be fixed for this is the package name
for the code. Currently it's "cqpid", which isn't close to what we have
in other languages (which all use a variable on qpid.messaging).
However, we can't use that since it's what our pure Python code uses.
Or can we?
That's t
12 matches
Mail list logo