Question: Is it better than aioamqp ?

socketpair commented 8 years ago

https://github.com/Polyconseil/aioamqp

asvetlov commented 8 years ago

@Drizzt1991 maybe you have 5 cents to put in?

tvoinarovskyi commented 8 years ago

Hello. Frankly both aren't good. Few points about both projects:

aioamqp has a bad interface. It resolves purely around callbacks, and it's in the world of asyncio where we have async for and async with constructs...
I think aioamqp is still a pet project (not that asynqp is better). I didn't contribute to it, but at a slight look can say it's somehow naive in handling things. The methods are not cancellable, socket connections don't actually have proper finalization...
asynqp has potential (at least for me) in the API. It clearly states what's public and how to use things.
But asynqp is not supported. At least no active initiative here. Author does not have time to add features. As for me, I think that asynqp's test suite is Horrible, really it's so hard to add anything, it's killing me. If @benjamin-hodgson would consider to allow changing the test suite to lets say py.test I would be happy to keep the project alive, but with current one...
asynqp at the latest released version (0.4) is not usable, the master is ok, but I still use a separate branch in my fork for builds, as I need some features, that benjamin didn't approve.

benjamin-hodgson commented 8 years ago

Hello!

I can't speak for aioamqp, but @Drizzt1991's assessment of the status of this project is more-or-less accurate. I'm still keeping half an eye on pull requests and issues (hence this message!) but I don't really have the time to keep the library under active development. The bits that exist do work, but I wouldn't consider the library production-ready.

I hear your complaints about the test suite. The framework is quite opinionated, which reflects the way I was thinking about testing at the time that I wrote it. Those opinions aren't wrong but my thinking has mellowed somewhat since then. That said, the tests themselves aren't bad in my opinion - they are decoupled from the implementation of the library and they offer good code coverage. So I'd be open to helping translate the tests into a more traditional xunit style (I would choose pytest), while keeping the overall structure of the tests intact.

I would like to extend the API to be compatible with Python 3.5's async/await constructs. However, that mustn't be at the expense of a natural experience for Python 3.4 users. The API should degrade gracefully when language features are missing.

tvoinarovskyi commented 8 years ago

Sounds great! How about we make a v0.5 release with the current one and rewrite it to py.test in v0.6. Could you create a milestone and mark what should we close for v0.5, we did quite a lot from v0.4. I'll be happy to close it.

asvetlov commented 8 years ago

+1

On Mon, Feb 29, 2016 at 11:59 AM, Taras Voinarovskyi < notifications@github.com> wrote:

Sounds great! How about we make a v0.5 release with the current one and rewrite it for v0.6. Could you create a milestone and mark what should we close for it. I'll be happy to close it.

— Reply to this email directly or view it on GitHub https://github.com/benjamin-hodgson/asynqp/issues/67#issuecomment-190287951 .

Thanks, Andrew Svetlov

benjamin-hodgson commented 8 years ago

Done. You seem keen to get 0.5 out soon so I just labelled bug-fixes. New features and API changes can wait. Let me know if you think I've missed anything. https://github.com/benjamin-hodgson/asynqp/milestones/v0.5

dzen commented 8 years ago

Hello @Drizzt1991, thank you for your honesty. I'm currently sure of the state of both projects and tha'ts probably why they still are in 0.xx version.

I think we concentrated our efforts on the AMQP implementation rather than thinking "How would I use the library ?" to have a clean and slick lib.

Don't hesitate to submit your ideas and open issues on what's really wrong with the code / the usage you made of it.

benjamin-hodgson / asynqp

Question: Is it better than aioamqp ? #67