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

taskw #1078

Open
ryneeverett opened this issue Nov 13, 2024 · 3 comments
Open

taskw #1078

ryneeverett opened this issue Nov 13, 2024 · 3 comments

Comments

@ryneeverett
Copy link
Collaborator

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

@KevinMFong
Copy link

Has switching to tasklib been considered? I recognize it's a big project, but tasklib is already in GothenburgBitFactory, and this could be a good opportunity to consolidate the community on a single library for interfacing with the taskwarrior database.

@ryneeverett
Copy link
Collaborator Author

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.

@KevinMFong
Copy link

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.

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