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 example, call the wrapped client cqpid.messaging but make it easy
for a distro to build and package it as qpid.messaging.
-Ted
On 07/09/2013 03: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 what our pure Python code uses.
Or can we?
That's the question: how do we package up the code? I've experimented
with the examples we have and they seem to work just fine with cqpid
substituted for qpid.messaging for the imports.
If our goal is to eventually replace the pure Python with the swigged
version, then we could use the same package with a note to users that
they need to pick one or the other. This would give us a clear migration
path.
Ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
