Skip to content

Commit a584b5e

Browse files
committed
some minor bugfixes on the compatibility hints project plus changelog updates
1 parent f08beec commit a584b5e

2 files changed

Lines changed: 24 additions & 20 deletions

File tree

CHANGELOG.md

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
## IMPORTANT - "flapping" changeset!
44

5-
The requests library is stagnant, so in 2.0.0 I replaced it with a fork niquests. It's a very tiny changeset, and three github issues could be closed just by doing this switch. In addition niquests supports HTTP/2 and is one possible way forward for implementing async support. However, the change has proven controversial, shortly after releasing 2.0 I had to revert back to requests and release 2.0.1. Right after releasing 2.0.1, I reverted again so that the master branch is using niquests.
5+
The requests library is stagnant, so in 2.0.0 I replaced it with a fork niquests (as someone recommended in a pull request). It's a very tiny changeset, and three github issues could be closed just by doing this switch. In addition niquests supports HTTP/2 and is one possible way forward for implementing async support. However, the change has proven controversial. The niquest author has not been able to cooperate very well with the rest of the python community, so niquests pulls in a lot of other forked libraries as for now. Shortly after releasing 2.0 I had to revert back to requests and release 2.0.1. Right after releasing 2.0.1, I reverted again so that the master branch is using niquests.
66

77
My plan now is to keep doing dual releases while maintaining the 2.x-series - one with niquests and one with requests. You are encouraged to make an informed decision on weather you are most comfortable with the stable but stagnant requests, or the niquests fork and choose your version accordingly. When I'm starting to work on 3.0 (which will support async requests), I will think deeply about this and either choose niquests, httpx, or (it's always possible to hope!) requests 3.0. **Your opinion is valuable for me**. Feel free to comment on https://github.com/python-caldav/caldav/issues/457, https://github.com/python-caldav/caldav/issues/530 or https://github.com/jawah/niquests/issues/267 if you have a github account, and if not you can reach out at python-http@plann.no
88

@@ -18,7 +18,8 @@ This project should adhere to [Semantic Versioning](https://semver.org/spec/v2.0
1818

1919
### Changed
2020

21-
* In 1.5.0, I moved the compability matrix from the tests directory and into the project itself - now I'm doing a major overhaul of it. This change is not much visible for end users yet - but already now it's possible to configure "compatibility hints" when setting up the davclient, and the idea is that different kind of workarounds may be applied depending on the compatibility-matrix. Search without comptype is wonky on many servers, now the `search`-method will automatically deliver a union of a search of the three different comptypes if a comptype is not set in the parameters *and* it's declared that the compatibility matrix does not work. In parallell I'm developing a stand-alone tool caldav-server-tester to check the compatibility of a caldav server.
21+
* In 1.5.0, I moved the compability matrix from the tests directory and into the project itself - now I'm doing a major overhaul of it. This change is not much visible for end users yet - but already now it's possible to configure "compatibility hints" when setting up the davclient, and the idea is that different kind of workarounds may be applied depending on the compatibility-matrix. Search without comp-type is wonky on many servers, now the `search`-method will automatically deliver a union of a search of the three different comp-types if a comp-type is not set in the parameters *and* it's declared that the compatibility matrix does not work. In parallel I'm developing a stand-alone tool caldav-server-tester to check the compatibility of a caldav server. https://github.com/python-caldav/caldav/issues/532 / https://github.com/python-caldav/caldav/pull/537
22+
* Littered the code with `try: import niquests as requests except: import requests`, making it easier to flap between requests and niquests.
2223

2324
### Fixes
2425

@@ -205,7 +206,7 @@ Since the roadmap was made, the maintainer has spent 39 hours working on the Cal
205206

206207
### Fixed
207208

208-
* Partial workaround for https://github.com/python-caldav/caldav/issues/401 - some servers require comptype in the search query -
209+
* Partial workaround for https://github.com/python-caldav/caldav/issues/401 - some servers require comp-type in the search query
209210
* At least one bugfix, possibly fixing #399 - the `accept_invite`-method not working - https://github.com/python-caldav/caldav/pull/403
210211
* Fix/workaround for servers sending MAILTO in uppercase - https://github.com/python-caldav/caldav/issues/388, https://github.com/python-caldav/caldav/issues/399 and https://github.com/python-caldav/caldav/pull/403
211212
* `get_duration`: make sure the algorithm doesn't raise an exception comparing dates with timestamps - https://github.com/python-caldav/caldav/pull/381

caldav/compatibility_hints.py

Lines changed: 20 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -185,6 +185,8 @@ def copyFeatureSet(self, feature_set, collapse=True):
185185
def collapse(self):
186186
"""
187187
If all subfeatures are the same, it should be collapsed into the parent
188+
189+
Messy and complex logic :-(
188190
"""
189191
features = list(self._server_features.keys())
190192
parents = set()
@@ -199,23 +201,24 @@ def collapse(self):
199201

200202
if len(parent_info['subfeatures']):
201203
foo = self.check_support(parent, return_type=dict, return_defaults=False)
202-
dont_collapse = False
203-
for sub in parent_info['subfeatures']:
204-
bar = self._server_features.get(f"{parent}.{sub}")
205-
if bar is None:
206-
dont_collapse = True
207-
break
208-
if foo is None:
209-
foo = bar
210-
elif bar != foo:
211-
dont_collapse = True
212-
break
213-
if not dont_collapse:
214-
if not parent in self._server_features:
215-
self._server_features[parent] = {}
204+
if len(parent_info['subfeatures']) > 1 or foo is not None:
205+
dont_collapse = False
216206
for sub in parent_info['subfeatures']:
217-
self._server_features.pop(f"{parent}.{sub}")
218-
self.copyFeatureSet({parent: foo})
207+
bar = self._server_features.get(f"{parent}.{sub}")
208+
if bar is None:
209+
dont_collapse = True
210+
break
211+
if foo is None:
212+
foo = bar
213+
elif bar != foo:
214+
dont_collapse = True
215+
break
216+
if not dont_collapse:
217+
if not parent in self._server_features:
218+
self._server_features[parent] = {}
219+
for sub in parent_info['subfeatures']:
220+
self._server_features.pop(f"{parent}.{sub}")
221+
self.copyFeatureSet({parent: foo})
219222

220223
def _default(self, feature_info):
221224
if isinstance(feature_info, str):
@@ -591,7 +594,7 @@ def dotted_feature_set_list(self, compact=False):
591594
radicale = {
592595
"search.comp-type-optional": {"support": "ungraceful"},
593596
"search.category.fullstring": {"support": "unsupported"},
594-
"search.recurrences.expanded": {"support": "unsupported"}, ## This was apparently broken in commit 9d591bd5144c97ae3803512b6c22cd5ce1dfd0f9 and 371d5057de6a1f729d198ab738dd6e19c9e55099 - issue has been raised in https://github.com/Kozea/Radicale/issues/1812#issuecomment-3067913171
597+
"search.recurrences.expanded": {"support": "unsupported"}, ## For events, there is https://github.com/Kozea/Radicale/issues/1827 causing the test code to fail. Unfortunately the compatibility checks pass. For tasks, the master branch works as of 2025-07-20, but the latest release doesn't.
595598
'old_flags': [
596599
## calendar listings and calendar creation works a bit
597600
## "weird" on radicale

0 commit comments

Comments
 (0)