Skip to content
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

the future of happybase #233

Open
wbolster opened this issue Nov 29, 2019 · 5 comments
Open

the future of happybase #233

wbolster opened this issue Nov 29, 2019 · 5 comments

Comments

@wbolster
Copy link
Member

wbolster commented Nov 29, 2019

considering that:

  • happybase is quite a mature and stable library
  • happybase is widely used
  • happybase has not seen much development lately
  • the original author (me, @wbolster) is not very active as a maintainer anymore
  • various pull requests and bug reports have not received proper attention
  • @aiudirog has recently done fantastic work on making an async version of happybase: aiohappybase
  • the same aiohappybase work modernizes the code to be python3.6+ only
  • the EOL dates of python2 and python3.5 are in the near future

it may be good for happybase's future if:

thoughts welcome, especially from @aiudirog (with whom i also have had recent email contact).

@wbolster
Copy link
Member Author

i've transferred my wbolster/happybase github repository into a new python-happybase github organisation (unfortunately happybase was taken already), and i've invited @aiudirog to become a co-owner of this new github org.

@aiudirog
Copy link
Member

I should have my third idea for merging the two forks (where async is the default) fleshed out by tomorrow.

With that finished, it wouldn't be very hard at all to create a happybase package that just inverts the imports of the aiohappybase package to provide the strict supperset without code duplication that could serve as a nice transition period.

@aiudirog
Copy link
Member

aiudirog commented Dec 3, 2019

I've finished the "sync as a sub-package" implementation: https://github.com/aiudirog/aiohappybase/pull/3

It's a little hacky in its pursuit of code dryness but I think that's okay because in theory it will nearly guarantee the two implementations don't diverge without having to code everything twice.

@aiudirog
Copy link
Member

I went through the open PRs and added counters to Batch and append() to Table. Between those two changes and some of the ones I had already made, #192, #175, #125, #96, and #89 should be satisfied.

@wbolster
Copy link
Member Author

this is fantastic, thank you for all your work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants