-
Notifications
You must be signed in to change notification settings - Fork 208
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
taskw #1078
Comments
Has switching to tasklib been considered? I recognize it's a big project, but |
Thanks for brining tasklib to my attention! I was aware of it but assumed that it would not support taskwarrior-3. I was wrong. Unfortunately, tasklib appears to be in the same boat as taskw with respect to maintainership and appears to implement the taskwarrior integration very similarly to tasklib. So I doubt switching to tasklib would inherently solve any problems but it might be a better way to consolidate the maintenance burden. |
No problem! FWIW I'd also be interested in helping to maintain either taskw or tasklib, depending on which one bugwarrior decides to go with. I myself have fallen into the "trap" of using both libraries for the same thing (e.g., Taskwarrior hooks). Also, thank you for maintaining bugwarrior! It's one of my favorite CLI apps, and I use it everyday. |
Bugwarrior currently depends on taskw to interface with the taskwarrior database. While there is an implementation which interacts with the taskwarrior-2 database files directly, bugwarrior has for some time used the interface which interacts through the
task
shell command. This turned out to be a fortunate choice, because bugwarrior continues to work with taskwarrior-3 even though it has a totally different database.However, taskw currently lacks much in the way of maintenance. Ralph offered to transfer taskw to GothenburgBitFactory earlier this year, but there were some communication issues which prevented that from happening. I don't think there's any question that this is an option and that all parties are open to it, but I am unsure who has the interest and skill to maintain taskw if that transfer were made. I would be willing to try to help if that were the path forward, but my recollection is that taskw maintenance was particularly difficult because it was hard to fix something for one dependent application without introducing bugs in another dependent application.
I'd be remiss if I didn't mention that I've become aware of taskw-ng, a fork (or rewrite?) which appears to be maintained. It also might be worth considering asking bergercookie to be a taskw maintainer if it were to be transferred to GothenbergBitFactory. I haven't looked at it closely at all.
In addition to the current lack of a maintainer, we have always had a few buggy edge cases in which certain data can't be serialized such that it is interpreted correctly by the shell. I suspect we're dealing with another one in #1075, which got me thinking about this this week.
Another option at this particular moment would be to create a taskw shim package in bugwarrior which mimics the small portion of the taskw API we currently use and integrates with taskchampion (the taskwarrior-3 database). We could then use our shim package and fall back to the real taskw for taskwarrior-2 users. (The motivation to continue supporting taskwarrior-2 may expire before this issue is resolved, in which case the shim API is irrelevant...) I created a separate issue about integrating with taskchampion: #1077
The text was updated successfully, but these errors were encountered: