2022-09-18 20:43:40.528 ERROR (MainThread) [homeassistant.components.sensor] email: Error on device update!
Traceback (most recent call last):
File "/var/lib/hass/.local/lib/python3.10/site-packages/homeassistant/helpers/entity_platform.py", line 493, in _async_add_entity
await entity.async_device_update(warning=False)
File "/var/lib/hass/.local/lib/python3.10/site-packages/homeassistant/helpers/entity.py", line 703, in async_device_update
await task
File "/usr/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/var/lib/hass/custom_components/email/sensor.py", line 126, in update
server = IMAPClient(self.imap_server, use_uid=True, ssl=self.ssl)
File "/var/lib/hass/deps/lib/python3.10/site-packages/imapclient/imapclient.py", line 254, in __init__
self._imap = self._create_IMAP4()
File "/var/lib/hass/deps/lib/python3.10/site-packages/imapclient/imapclient.py", line 288, in _create_IMAP4
return tls.IMAP4_TLS(self.host, self.port, self.ssl_context,
File "/var/lib/hass/deps/lib/python3.10/site-packages/imapclient/tls.py", line 44, in __init__
imaplib.IMAP4.__init__(self, host, port)
File "/usr/lib/python3.10/imaplib.py", line 202, in __init__
self.open(host, port, timeout)
TypeError: IMAP4_TLS.open() takes 3 positional arguments but 4 were given
I've debugged the issue a bit, and to my dismay it was already solved in imapclient >=2.2.0, but this project pins the version to 2.1.0 which doesn't have the fix.
I've personally tested bumping the package dep to 2.3.1 ( current release ) and it works.
Since the changelog doesn't list any api-breaking changes since version 1.0, I'd argue for removing the needless pinning entirely so that users can get a more up to date lib if they wish so; If you really want to be strict about api breakage, then setting an upper bound for a major release of <3 should suffice and only require manual intervention in a distant future.
I've debugged the issue a bit, and to my dismay it was already solved in imapclient >=2.2.0, but this project pins the version to 2.1.0 which doesn't have the fix. I've personally tested bumping the package dep to 2.3.1 ( current release ) and it works.
Since the changelog doesn't list any api-breaking changes since version 1.0, I'd argue for removing the needless pinning entirely so that users can get a more up to date lib if they wish so; If you really want to be strict about api breakage, then setting an upper bound for a major release of <3 should suffice and only require manual intervention in a distant future.