vert-x3 / vertx-eventbus-bridge-clients

Home for various EventBus Bridge clients
Other
65 stars 33 forks source link

fix python vertx-eventbus-bridge-client #26

Open WolfgangFahl opened 4 years ago

WolfgangFahl commented 4 years ago

Version

3.8.5

Context

I'd love to use python in a vert.x context

To get things better tested and integrated I started (a maybe temporary) project:

which should allow self-contained testing and integration.

There is also a chat room available at:

This issue should be closed if the results of the project could be reintegrated here.

BFergerson commented 3 years ago

PR #50 mentions this work. Is the above repo necessary anymore and if so, what's left?

I have an interest in seeing the Vert.x Python client improved and published to PyPI and I'm willing to offering bounties to make that happen. If the bounties don't work I'll likely end up doing it myself but I wanted to see if anyone with more experience in Python is willing. I see @gaol is the latest maintainer. Do you have any availability? If so, I would like to offer bounties for the following:

Automated PyPI publish workflow

I started my Python project using https://github.com/dapangmao/vertx-python-client. I wasn't able to tell which of the Python clients were the best so I just used that one since it's on PyPI. The Python client in this repo is the official one, it should be on PyPI as well.

Automatic reconnection logic

It doesn't appear there is reconnection logic in the Python client. If I turn my server on after I turn on the Python client, it'll just fail with ConnectionRefusedError. It doesn't matter what I put for timeout as it'll instantly fail and then run through all the max_reconnect retries instantly.

TLS support

I didn't look exhaustively, but it doesn't seem the Python client supports TLS.

gaol commented 3 years ago

@BFergerson thanks for the feedback. :)

Automated PyPI publish workflow

The publish belongs to Vert.x leader @vietj , we agreed to do publish manually instead of making it automatically to make it simple.

Automatic reconnection logic

The timeout is for the socket itself. I agree that the client should be more patient to wait for the server to come up. :) I created https://github.com/vert-x3/vertx-eventbus-bridge-clients/issues/53 to track the issue.

TLS support

Thanks, I created https://github.com/vert-x3/vertx-eventbus-bridge-clients/issues/54 to track it.

I am willing to but I cannot guarantee the time because I am working on other projects as well. Any contributions from the community are very welcome, so if you are interesting, would you please work on these(or one of them) :)

After the issues get fixed, we can ask @vietj for a release to PyPi.

WolfgangFahl commented 3 years ago

see also https://github.com/rc-dukes/vertx-eventbus-python/issues/7

WolfgangFahl commented 3 years ago

In the mentime i have moved on and don't use Java much any more - I'd still be interested in the python side of things ...

BFergerson commented 3 years ago

@gaol, would you mind elaborating on the choice to manually publish as opposed to automatically publishing and how that makes things more simple? I take the opposite stance. I'm not saying that the Python bridge needs to be updated every time Vert.x is updated. I'm just advocating for a workflow as requiring a human to do manual updates seems tedious and error-prone.

Python isn't my strongest language which is why I mentioned bounties. If I end up doing these tasks, I'd just hire a freelancer. I figured I'd start by asking those closest to the project what would motivate them to do it.

gaol commented 3 years ago

@BFergerson I think one reason is that multiple clients share this git repository, we need to distinguish the changes belonging to which client. we don't need to worry about it if we release manually, it is simple command for Python client: python/build.sh --publish

I opened a PR #55 to address the re-connection issue, would you please review if you like? Thanks :)

As the comment above said, any kind of contributions are welcome, we are glad to see more people get involved in this project. and I will try my best to coordinate the release. :)

BFergerson commented 3 years ago

That makes a bit of sense. I'd argue each client could just have their own publishing workflow, but whatever gets the job done.

Thanks for the quick PR, @gaol. Functionally it works perfectly. Just found some lint issues.

BFergerson commented 3 years ago

@gaol, would you mind publishing the first release to PyPI?

Edit: Thanks for publishing.