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

Reply via email to