Calendar and contact infrastructure

[matrss]

Description

I wanted to setup vdirsyncer today and stumbled across the old PRs for calendar and contact infrastructure and associated with that the vdirsyncer and khal modules in #899. It seems like that got removed at some point though, but I could not find any discussion around the removal. Was that intentional or was it lost due to something like force-pushing as happened in #775?

I guess this can be considered a feature request for a vdirsyncer module or again a full-blown calendar and contact infrastructure, if that is wanted.

If I overlooked some discussion though I'd be happy to get a link.

[sumnerevans]

There was some progress here: #754

I think the biggest thing is just that nobody has had the time to create the full-blown calendar/contact infrastructure; it's a lot of work.

I think that whoever makes the next attempt at building it out should try to do it as iteratively as possible. We don't need to get the whole thing done in one swoop, I am (and I'm sure @berbiche and @rycee are) more than happy to merge in incremental steps that are self-contained but move us in the correct direction.

[RaitoBezarius]

FWIW, for vdirsyncer; here's: https://github.com/RaitoBezarius/nixos-home/blob/master/calendar.nix + https://github.com/RaitoBezarius/nixos-home/blob/master/modules/vdirsyncer.nix

[RaitoBezarius]

Alas, I do not have any time to upstream them at the moment.

[Misterio77]

I'm very interested in getting vdirsyncer, todoman, khard, and khal working. I might give this a shot

[stale]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[ambroisie]

@berbiche shouldn't this be re-opened ?

[stale]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[ambroisie]

Still relevant.

[jorsn]

Quotes here are from #2335 (comment).

I think the biggest thing is just that nobody has had the time to create the full-blown calendar/contact infrastructure; it's a lot of work.

Who defines what full-blown means?

I think, the problem back then was not that nobody had the time to create something, but that at some point no authority (with merge access) had the time or interest to give feedback and define what we should do to get something merged, or whether there was any reason not to merge (see 1,2,3). So we ended up just implementing what we were using ourselves and maintaining our personal fork (= fixing the same merge conflict on every update, at Git's fault (possible solution)).

I think that whoever makes the next attempt at building it out should try to do it as iteratively as possible. We don't need to get the whole thing done in one swoop, I am (and I'm sure @berbiche and @rycee are) more than happy to merge in incremental steps that are self-contained but move us in the correct direction.

The old branch worked, and my khard extension as well. As I see it, if being too monolithic was a problem of the old attempt, it was only the framing, not the actual code/content. Maybe it is better to narrow the whole thing down to only supporting (extended) pimutils.

My conclusion is that for a new attempt to be successful, we would need a committed developer¹ and a clear statement by someone with merge access (is it only @rycee?) of what they would accept, and a clear sign that this is high enough on their priority list to be merged eventually.

Footnotes

1. only for polishing what is already pretty finished, and maybe adding todoman ↩

[teto]

I am interested in this but was worried about vdirsyncer since at the time it seemed unsupported. Ideally we would have someone invested in this as a HM collaborator (with merge rights) since this is definitely going to be an active part of HM.

[d-dervishi]

I'm also interested in this. I'd like to add calendar support to the Thunderbird module, but I'd rather avoid writing Thunderbird-specific options just to remove them once a shared infrastructure is implemented. Is anyone working on this? Are @jorsn's comments still relevant?

[teto]

seems like we have several candidates for a common architecture: thunderbird, khard, todoman.
As stated earlier I am willing to review/merge PRs (but can't actively work on a PR).

[RaitoBezarius]

I can send vdirsyncer stuff that I have.

[RaitoBezarius]

First step #3912

[teto]

I've merged the 4/5 year old branch #4078 instead of waiting for the perfect MR (perfect is the enemy of good). This is the beginning of a new cycle so we have 6 months to make the calendar infra "right" (hopefully less). So please start using it and let's not be afraid of refactors/breaking stuff. I've merged because I could configure khal /vdirsyncer with it but ofc there are things I am not happy with it.

[DanielSiepmann]

Thanks for bringing this forward @teto. I'll try to migrate and provide feedback.

• Maybe we should trim traililing "/" from basePath. I added a trailing "/" which ended up in wrong paths for khal.
• warning: unknown key or subsection "highlight_event_days" in section "[calendars][[private]] comes when executing khal interactive. I'm on nixpkgs unstable.
• Looks like modules/services/vdirsyncer.nix is not included yet.
• I've multiple accounts with multiple calendars. It looks like this isn't possible with khal yet? As it will add one calendar per account. It uses some /* at the end. But opening khal interactive will create a folder * instead of fetching events from all folders. Looks like this should only be used if type is set to discover. But * is always added, ignoring the type. Maybe this is broken right now? I guess the hardcoded /* should be removed and the existing code would work picking up globPath with default * if set to discover?

I hope my feedback is helpful. Don't hesitate to get in contact with me.

[teto]

@DanielSiepmann thanks for the feedback

warning: unknown key or subsection "highlight_event_days" in section "[calendars][[private]]

indeed. Will remove it. I think the key exists but maybe as a global instead. We shouldn't change defaults but I would like to be able to set this option. Its something that escaped my fork.

Looks like modules/services/vdirsyncer.nix is not included yet.

bad me, I need to double check later.

I've multiple accounts with multiple calendars. It looks like this isn't possible with khal yet?

I have only one account that is multicalendar and adding /* at the end of the caldav sync worked for me but it may have broken the single calendar scenario. I am not sure if I merged that. I need to do another pass. Thanks for feedback.

[DanielSiepmann]

@teto feel free to ping me within PRs. I'll try to test them with my setup. I've a separate branch with my migration as WIP.

I have only one account that is multicalendar and adding /* at the end of the caldav sync worked for me but it may have broken the single calendar scenario. I am not sure if I merged that. I need to do another pass. Thanks for feedback.

I needed to set the following in order to make discovering work with current state:

          type = "discover";
          glob = "";

As this will lead to

path = /home/daniels/.local/share/vdir/calendars/private//*
type=discover

/* needs to be added. But that seems to be the default for glob already which is used when type is set to discover. But it should not be added if type is not discover. https://github.com/nix-community/home-manager/blob/master/modules/programs/khal.nix#L32 always adds the globbing right now.

[teto]

@DanielSiepmann you seem to know more than I do + I dont think I will be able to address that today so feel free to prepare a PR if you are interested and tag me .

[DanielSiepmann]

@teto I've created two small PRs. One "fixes" the discover / globbing of khal: #4088 The other adds the missing include: #4089

I was able to fully migrate my existing setup to the new one.

The highlight_event_days warning only appears for "calendar" entries. But docs don't mention any limitation and it is only a warning.

[DamienCassou]

I think we should close this issue and maybe open dedicated ones if there are still problems.