-
Notifications
You must be signed in to change notification settings - Fork 6
New zocalo.util.rabbitmq.RabbitMQAPI #140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Adds requests_mock dev dependency
Pass if_unused/empty parameters to queue_delete
To simplify interface
This pull request introduces 1 alert when merging d7197ce into a7a1ff8 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging 5b92239 into a7a1ff8 - view on LGTM.com new alerts:
|
This line isn't hit in the tests, and it isn't trivial to inject fake credentials via the test.
This pull request introduces 1 alert when merging e91b751 into a7a1ff8 - view on LGTM.com new alerts:
|
src/zocalo/util/rabbitmq.py
Outdated
@create_component.register | ||
def exchange_declare(self, exchange: ExchangeSpec): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting use of singledispatch 🤔
src/zocalo/util/rabbitmq.py
Outdated
@delete_component.register | ||
def _delete_exchange(self, exchange: ExchangeSpec, **kwargs): | ||
self.exchange_delete(vhost=exchange.vhost, name=exchange.name, **kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But surely this one should just be called def _(...):
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did have it as def _(...)
but then mypy complains about it, see eg. python/mypy#2904
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this style is acceptable, I slightly prefer it - I still read the function name first, but all the examples I could find for singledispatch used this style.
tests/util/test_rabbitmq.py
Outdated
rmqapi.exchange_declare(exchange=exchange_spec(name)) | ||
rmqapi.create_component(exchange_spec(name)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So do these two calls not do the same thing then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd added the {exchange,queue}_{declare,delete}
etc methods originally, more closely mirroring either the pika or rabbitmqctl interfaces, and then later added the {create,delete}_component
interfaces for compatibility with what @d-j-hatton did in his original implementation of the configuration script. E.g. queue_delete
and delete_component(queue)
have different interfaces, as you can call the former with just the vhost
and name
strings, whereas the latter expects a full QueueSpec
object.
This pull request introduces 1 alert when merging 24ebf4c into a7a1ff8 - view on LGTM.com new alerts:
|
I used a |
Since the |
I think either way is fairly simple. The single dispatch method could just be changed to call a single dispatch that doesn't live inside the class. I don't mind either direction. Any preferences? |
functools.singledispatchmethod is Python 3.8+ only
I've removed the |
This pull request introduces 1 alert when merging 7c3e26b into 5f070ee - view on LGTM.com new alerts:
|
Provide a (not fully comprehensive) Python wrapper around the RabbitMQ HTTP API. Can be used to read various metrics useful for monitoring/health checks, and configuring exchanges, policies, queues, etc.
Adds explicit dependencies on pydantic and requests modules and a test dependency on requests-mock.
Alternative to #136