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

Is this project maintained? #87

Open
jeffwright13 opened this issue Aug 12, 2022 · 10 comments
Open

Is this project maintained? #87

jeffwright13 opened this issue Aug 12, 2022 · 10 comments

Comments

@jeffwright13
Copy link

Haven't seen any activity in a while. There are several PRs out that would improve it, but I don't seem them being addressed, either.

@a-luna
Copy link

a-luna commented Aug 18, 2022

I tried emailing the maintainer a long time ago (July 2021) asking if I could offer my services as a maintainer to help triage issues and deal with PRs, etc. No response whatsoever unfortunately.

@jeffwright13
Copy link
Author

Might have to fork it. Or, consider another library. Lots of areas for improvement.

@davedittrich
Copy link

I started using it in several projects years ago. Switching to another library (assuming one can be found that is similar in function and ease of use) would be a bit of work, but using an abandoned library is also unappealing. Any ideas of maintained alternatives? (Or can @a-luna let us know if you decide to fork?)

@jeffwright13
Copy link
Author

Well there is SimpleTerm https://pypi.org/project/simple-term-menu/ - I have not used it but at least there was a release a couple of months ago.

Maybe we should collectively take over this repo, or fork it and start making it better. Anyone want in with me? Or should I try the simple-term route to see if that's a reasonable alternative?

@a-luna
Copy link

a-luna commented Sep 4, 2022

Sorry for the delayed response, I would definitely be willing to fork and participate as a maintainer.

I do not have the bandwidth to take over the project solely by myself, but would love to help create/maintain the roadmap, merge/reject the current PR backload, and triage issues.

I would only be willing to move forward if the two of you (@jeffwright13 and @davedittrich) can commit to a similar workload. Any lurkers out there reading this please chime in if you would also be willing to help out.

However, it might be wise to create a single new release of bullet that merges critical PRs and fixes blocking issues and cease new development.

Why? Because @willmcgugan (creator of the excellent rich library (over ⭐️39K)) is working on a terminal UI framework called textual (over ⭐️13K) which honestly makes bullet look sad and unnecessary in comparison.

I can see there being an argument for bullet as a different category than textual, with a much, much smaller feature set that therefore makes it easier to learn, thus requiring less time to apply to a project. And if you really only need the menu system that bullet provides, trying to figure out how to create the same experience in textual would require a steep learning curve for no benefit since you won't ever use the other 95% of textual's features.

Sorry for this somewhat contradictory ramble of ideas, I'd love to hear both of your thoughts (and anybody else out there reading this, please reply as well!)

@jeffwright13
Copy link
Author

Hi @a-luna,

Yes, I would be willing to commit to such a workload. TBH this is a fairly small codebase, and I don't think it would be too much effort to get it into a state where it's meeting everyone's needs (i.e. PRs merged, critical bugs addressed, etc.). I would look to you for guidance on the roadmap but I can provide help with PR reviews, fixing issues, etc. I'd also like to see some tests put in place and possibly a Github Actions build/release train.

BUT - what I like about Bullet as it stands now is (1) the code is in place and it mostly works; (2) it's really easy to get off the ground and running without a lot of setup. :-)

As far as Textual goes, I'm not sure a full blown TUI is necessary for such a simple application as this, but maybe I am missing something. I can certainly see how Rich (the 'other' Will McGugan library that Textual depends on) would put a fresh face on Bullet though. I am pretty familiar with both Rich and Textual, having used Textual to build up a TUI for the pytest-tui plugin, so it would be fun to use those to make over Bullet.

@pzelnip
Copy link

pzelnip commented Apr 12, 2023

While I appreciate that textual is quite sophisticated & in that sense supersedes bullet, the thing I like about bullet is that it's so easy to just quickly get some simple prompts working. Textual's docs are a bit daunting as it does so much, so for small projects where you just want a Yes/No or Password input, Textual feels like overkill.

@h4rldev
Copy link

h4rldev commented Jun 4, 2023

@hlin-neo4j
Copy link

https://github.com/h4rldev/rebullet 👍

Hi! Would you mind providing a brief context on the pull requests and/or fixes you've applied in your fork? Thanks!

@h4rldev
Copy link

h4rldev commented Jun 27, 2023

https://github.com/h4rldev/rebullet 👍

Hi! Would you mind providing a brief context on the pull requests and/or fixes you've applied in your fork? Thanks!

  • I've merged most or all pull requests on this repo
  • Done some documentation fixes
  • Fixed some code structure
  • Fixed yesno

There might be more, I haven't worked on rebullet in a while, but I can say it works on 3.10, I don't really know if it works below 3.10, if it doesn't. Make a pull request that reverses these 3.10 only features 👍

Although I might not be able to fix any new issues right now, I haven't worked in python in a while, neither do I have my environment set-up, waiting on a new m.2 ssd.

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

6 participants