You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm doing a taskwarrior integration utilizing tasklib and there are UDAs in play. UDAs of type date and duration. They're represented as Python strings when acquired task["my_uda"], but I don't think this has to be the case - they could come out as datetime and timedelta IMO. Right now I'm parsing them manually in my integration, but actually this could be implemented in tasklib.
I'd be up for the job, however would like to first consult with some more experienced with the codebase - does it seem like a stupid idea due to architectural concerns or something else?
The text was updated successfully, but these errors were encountered:
allgreed
changed the title
Is there an interest in automatic UDA parsing?
Automatic parsing of time-related UDAs
Jul 27, 2024
The library appears to be stalled since 2022... I have simple PRs that have sat since then with no one looking at them. The last commits were in 2022. Furthermore, with TW3, it's possible this whole library will eventually wrap the database rather than TW itself, and/or be superseded by other interfaces.
Ironically this was the same problem that drove me from Ralph Bean's library to this one (I have PRs over there in same state) and then it happened to this one too.
Just saying, if you submit the PR, be prepared to work off your own copy for a while, possibly years or forever.
I'm doing a taskwarrior integration utilizing tasklib and there are UDAs in play. UDAs of type
date
andduration
. They're represented as Python strings when acquiredtask["my_uda"]
, but I don't think this has to be the case - they could come out asdatetime
andtimedelta
IMO. Right now I'm parsing them manually in my integration, but actually this could be implemented in tasklib.I'd be up for the job, however would like to first consult with some more experienced with the codebase - does it seem like a stupid idea due to architectural concerns or something else?
The text was updated successfully, but these errors were encountered: