The current [experimental] implementation is stale, and hasn't been
maintained for a long time. Regrettably, not even its tests still work,
and there nobody interested in maintaining it.
If anyone is interested in re-implementing this in a third-party
package, I can consider adding support for pluggable storages.
Not sure why we didn't do this initially, but this ensures that we
always close all connectors properly, and also gives much clearer scope
regarding their life-cycles.
Configure mypy as a pre-commit hook and add all type hints necessary for
mypy to pass.
There's still more work to be done here typing a lot more code, but this
provides a clear starting point.
- change the interface of Storage.get_meta() and .set_meta()
to use '' as the empty value and None as missing value.
- When a property is missing (e.g calendar-color was removed)
in the filesystem storage delete the 'color' file, and
in the WebDAV storage issue propertyupdate/remove call.
- remove the property from [status]/[pair]/[collection].metadata
I have adjusted, but not run the test suite. On the other side
I tested on real system: source is CalDAV - destination is filesystem;
and source is CalDAV, destination is CalDAV (another account)
- No need to empty collections, they're generated with a UUID and should
always be empty (the code to empty them does not actually run in CI
right now).
- Move deletion code to _after_ the yield, since that's the order in
which things happen.
- Delete all collections asynchronously.
The fix that disabled VTODO tests accidentally ran all other tests twice
for this storage.
This wasn't picked up earlier since Fastmail is not currently running on
CI.
Add asyncio to the storage backends and most of the codebase. A lot of
it merely uses asyncio APIs, but still doesn't actually run several
things concurrently internally. Further improvements will be added on
top of these changes
Thanks to Thomas Grainger (@graingert) for a few useful pointers
related to asyncio.
This adds A LOT of time to test execution, for little benefit. While
having random data is good, in reality, most of it was just numbers, and
we rarely got very diverse data.
These hand-picked samples are as good to catch any regressions or issues
with servers.
These submodules were used to bootstrap local test servers for running
integration tests.
We'll be reusing that codebase inside docker containers, but don't want
the containers built for each push to this repo -- that'll happen in a
separate repository.
