[BUG] events entered initially in Gcal get weird description when sync'd to taskwarrior

[bcohen44]

[BUG] events entered initially in Gcal get weird description when sync'd to taskwarrior

[bergercookie]

Nvm, it should be easy enough to tackle it on my side.
Fixed on latest master.

[bergercookie]

• What's the taskwarrior version you're using?
• What does this show ? task udas
• Can you show the full data of the task ? task 1

[bcohen44]

2.5.1 👎
Trying to update my system (Ubuntu 18)
sudo apt-get upgrade taskwarrior

Errors out with:

Traceback (most recent call last):
  File "/usr/lib/update-notifier/package-data-downloader", line 24, in <module>
    import debian.deb822
ModuleNotFoundError: No module named 'debian'
dpkg: error processing package update-notifier-common (--configure):
 installed update-notifier-common package post-installation script subprocess returned error exit status 1
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          dpkg: dependency problems prevent configuration of update-notifier:
 update-notifier depends on update-notifier-common (= 3.192.1.15); however:
  Package update-notifier-common is not configured yet.

dpkg: error processing package update-notifier (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 update-notifier-common
 update-notifier
E: Sub-process /usr/bin/dpkg returned an error code (1)

[bergercookie]

2.5.1

Yeah, that won't work for sure probably won't work. Try with >= 2.6

ModuleNotFoundError: No module named 'debian'

Sorry, no idea there.

[bergercookie]

I can't repro this with my 2.6 taskwarrior. Will close this and may re-open if more people report this.

[psanker]

I have this same issue with macOS. Task 5 was created on GCal.

❯ task 5

Name          Value
ID            5
Description   twgcalsyncduration:"PT86400S"
Status        Pending
Entered       2023-02-04 22:47:10 (4min)
Due           2023-02-06 00:00:00
Last modified 2023-02-05 03:19:24 ()
Tags          sync
Virtual tags  DUE LATEST MONTH PENDING QUARTER READY TAGGED UNBLOCKED YEAR
UUID          24d2a197-4848-4426-b8a7-d90dbc9dc080
Urgency       9.121

    tags    0.8 *    1 =    0.8
    due   0.693 *   12 =   8.32
                         ------
                          9.121

Using taskwarrior 2.6.2

❯ task --version
2.6.2

❯ task udas

Name     Type   Label    Allowed Values Default Usage Count
priority string Priority H,M,L,                 0

1 UDA defined

[bergercookie]

@psanker , I wonder if this has something to do with the twgcalsyncduration not being specified as a UDA in your taskrc file (which I I assumed was optional). Could you add the following to your taskrc?

Can you still reproduce this? Does it fix it?

uda.twgcalsyncduration.type=duration
uda.twgcalsyncduration.label=GCal duration

[psanker]

That does seem to have worked!

❯ task 10

Name          Value
ID            10
Description   This is a gcal test
Status        Pending
Entered       2023-02-05 11:10:25 (22s)
Due           2023-02-07 00:00:00
Last modified 2023-02-05 16:06:29 ()
Tags          sync
Virtual tags  DUE LATEST MONTH PENDING QUARTER READY TAGGED UDA UNBLOCKED YEAR
UUID          f7a6d959-f906-4de9-bf6a-2bcb52bbe993
Urgency       8.899
GCal duration P1D

    tags    0.8 *    1 =    0.8
    due   0.675 *   12 =    8.1
                         ------
                          8.899

Does that config have any ramifications for the use of tw_gcal_sync?

[bergercookie]

Thanks for verifying!

Custom UDAs shouldn't have to be explicitly defined. This seems to be an error with the underlying taskw python wrapper. Please file this as a bug in that project

https://github.com/ralphbean/taskw

[bergercookie]

Does that config have any ramifications for the use of tw_gcal_sync?

The twgcalduration is just a way of capturing the duration of the event so that we can have custom duration events. I think, since this is an issue with taskw AFAICT, the best thing we can do here is document it. We could also perhaps open .taskrc prior to execution and raise an error if this UDA is not set but I'd say this is rather a mitigation - the bug should be solved in its source.

[psanker]

Could this traceback be related at all? I put together a launchd launch agent and started seeing these errors in stderr.

Traceback (most recent call last):
  File "/usr/local/bin/tw_gcal_sync", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.10/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.10/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.10/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/Users/patrickanker/Library/Python/3.10/lib/python/site-packages/syncall/scripts/tw_gcal_sync.py", line 166, in main
    tw_side = TaskWarriorSide(tags=tw_tags, project=tw_project)
  File "/Users/patrickanker/Library/Python/3.10/lib/python/site-packages/syncall/taskwarrior/taskwarrior_side.py", line 55, in __init__
    self._tw = TaskWarrior(marshal=True, config_filename=config_file)
  File "/usr/local/lib/python3.10/site-packages/taskw/warrior.py", line 64, in __init__
    raise NotImplementedError(
NotImplementedError: You must use TaskWarriorShellout to use 'marshal'

[bergercookie]

No, not related I think.

I think this traceback was triggered because of launchd execution in the first place. It should always use the TaskWarriorShellout class to communicate with taskwarrior. Somehow, when launching via launchd, it couldn't initialize a TaskWarriorShellout instance and resorted to the older TaskWarriorDirect.

if TaskWarriorShellout.can_use():
    TaskWarrior = TaskWarriorShellout
else:
    TaskWarrior = TaskWarriorDirect

...

    @classmethod
    def can_use(cls):
        """ Returns true if runtime requirements of experimental mode are met
        """
        try:
            return cls.get_version() > LooseVersion('2')
        except FileNotFoundError:
            # FileNotFound is raised if subprocess.Popen fails to find
            # the executable.
            return False

    @classmethod
    def get_version(cls):
        try:
            taskwarrior_version = subprocess.Popen(
                ['task', '--version'],
                stdout=subprocess.PIPE
            ).communicate()[0]
        except FileNotFoundError:
            raise FileNotFoundError(
                "Unable to find the 'task' command-line tool."
            )
        return LooseVersion(taskwarrior_version.decode())

https://github.com/ralphbean/taskw/blob/develop/taskw/warrior.py