vdirsyncer: synchronize metadata as well

[somasis]

Description

Without this, the service will never synchronize things like calendar/contact
display names and calendar colors.

Checklist

• Change is backwards compatible.

• Code formatted with ./format.

• Code tested through nix-shell --pure tests -A run.all or nix develop --ignore-environment .#all using Flakes.

• Test cases updated/added. See example.

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • Added myself as module maintainer. See example.

[ncfavier]

Also see the discussion at #3912 (comment)

[somasis]

I think running vdirsyncer discover shouldn't be done automatically, since it's an opportunity where the user can determine if their configuration's list of collections will cause vdirsyncer to do something unintended (like creating a collection that doesn't exist on the remote).

I used to run yes y | vdirsyncer discover as part of my own vdirsyncer.service and it caused more problems than it solved, really.

Perhaps there could be a xdg.configFile."vdirsyncer/config".onChange hook to tell the user to run vdirsyncer discover to update the program's state to accompany configuration changes?

(maybe I should have commented this on that discussion, but I got the impression that it was an old pull request that was superseded by #4078)

[teto]

So I wonder why discover is necessary ? why can't it just download stuff ? or is it valuable in case you have local files already ?

In which case we could check if folder is empty and autorun discover in that case ?
Can we run discover in a way that fails only if user interaction is needed ?

When in doubt, I would choose caution and let user decide but we could make the task easier by warning him when input is needed (aka a failed discover)

[somasis]

So I wonder why discover is necessary ? why can't it just download stuff ? or is it valuable in case you have local files already ?

There's a small explanation in a tutorial in vdirsyncer's documentation:

Because collections are added rarely, and checking for this case before every synchronization isn’t worth the overhead.

https://vdirsyncer.pimutils.org/en/stable/tutorial.html?highlight=discover#id2

In which case we could check if folder is empty and autorun discover in that case ? Can we run discover in a way that fails only if user interaction is needed ?
When in doubt, I would choose caution and let user decide but we could make the task easier by warning him when input is needed (aka a failed discover)

Checking if the directory is empty seems like a good idea to me.

There's been some discussion upstream about how to automate vdirsyncer discover. pimutils/vdirsyncer#425 The old maintainer suggests doing yes | vdirsyncer discover (this is where I got that idea from).

If we want to run discover and just fail if any user input is necessary, we could check the exit status of yes n | vdirsyncer -v warning discover, since it'll exit non-zero if we respond n to a user prompt. I think this will also prevent it from doing anything funny with collections that might be unintentional. (using -v warning is just a good idea so we don't spam the system journal when there's nothing wrong).

[teto]

If we want to run discover and just fail if any user input is necessary, we could check the exit status of yes n | vdirsyncer -v warning discover

sounds good to me.

We could also make this configurable as a nix option: discover = "yes" / "ask" / "manual".

[sumnerevans]

I personally think that this incremental improvement is worth merging as-is. We can implement "discover" in a later PR.

[teto]

I personally think that this incremental improvement is worth merging as-is. We can implement "discover" in a later PR.

That is the spirit of calendar merge so I am fine with that. In case we merge the current, we just need to make sure the previous discussion doesn't get lost as it's valuable.

[somasis]

Sorry for the noise, should be all good this time though.

I personally think that this incremental improvement is worth merging as-is. We can implement "discover" in a later PR.

Agreed.

[teto]

tested it. Seems to work, probably not related but the first time the job failed and asked me to run vdirsyncer discover calendar_fastmail first