[macOS] maestral 1.3.1 compatibility with keyring: No module named 'keyring.backends.OS_X'

[barracuda156]

This is probably unsupported, but maybe you could give an advice. I have installed maestral 1.3.1 on 10.6, and trying running it fails with:

36-32% maestral link
2023-11-06 11:20:16,429 - [bugsnag] WARNING - No API key configured, couldn't notify
Traceback (most recent call last):
  File "/opt/local/bin/maestral", line 8, in <module>
    sys.exit(main())
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/maestral/cli.py", line 226, in wrapper
    return func(*args, **kwargs)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/maestral/cli.py", line 720, in link
    with MaestralProxy(config_name, fallback=True) as m:
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/maestral/daemon.py", line 693, in __init__
    from .main import Maestral
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/maestral/main.py", line 32, in <module>
    from .client import CONNECTION_ERRORS, DropboxClient, convert_api_errors
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/maestral/client.py", line 44, in <module>
    from .oauth import OAuth2Session
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/maestral/oauth.py", line 14, in <module>
    import keyring.backends.OS_X  # type: ignore
ModuleNotFoundError: No module named 'keyring.backends.OS_X'

Indeed, there is no such naming:

36-32% /opt/local/bin/keyring-3.10 --list-backend
dbus[37120]: Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
dbus[37120]: Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.chainer.ChainerBackend (priority: 10)
keyrings.alt.file.PlaintextKeyring (priority: 0.5)
keyrings.alt.file.EncryptedKeyring (priority: 0.6)
keyring.backends.macOS.Keyring (priority: 5)

Should I just patch in macOS instead? Or it will not work with a recent keychain, and I need to dig out some old version of it to make it work?

[samschott]

You can try installing an older version of keyring. IIRC, the "backend" rename from OS_X to macOS is a keyring internal rename only and has nothing to do with macOS keychain APIs.

[samschott]

Closing this is not anything fixable on the Maestral side. Newer releases of keyring and maestral address this issue if they can be installed.

[barracuda156]

@samschott I kinda forgot, what was the constraint we faced for older MacOS? Besides Qt GUI, that cannot work with Qt5 presently.

Something like fsevents issue? Maybe it is possible to have it working with some limitations, depending on what SDK features that requires.

[samschott]

If I remember correctly, there should be no fundamental constraint by Maestral itself. Installing Python and the maestral-cocoa Python package should still work.

Rather, the briefcase packing tool that I am using only support macOS 11 and later. I believe this makes it easier to target both Intel and Apple Silicon Macs.

[barracuda156]

@samschott Anything Cocoa is likely not to work, even if it installs (i.e. pure Python code may install, but SDK won’t have what it expects).

If there is an X11 / GTK3 version, there we have more chances IMO.

[barracuda156]

@samschott Ah, py-watchdog was the constraint: https://github.com/gorakhargosh/watchdog/issues/1021

The current maestral won’t work with that old version, right?

[samschott]

It won't, I'm afraid. The FSEvents backend for watchdog fixes a several fundamental sync and performance issues from the previously used kqueue backend.

The days of macOS 10.6 are numbered, as nice and stable as Snow Leopard was!

[barracuda156]

The FSEvents backend for watchdog fixes a several fundamental sync and performance issues from the previously used kqueue backend.

I see. Well, it may be possible to reimplement the thing so that watchdog can use that backend, or, if unsupported functions are non-critical, just use a partial fsevents implementation from the 10.6 SDK. But yeah, that requires time, and time is scarce…

The days of macOS 10.6 are numbered, as nice and stable as Snow Leopard was!

If only Apple had opensourced complete sources for the OS, we would probably have everything we need by now :)

Still, I routinely see cases when something builds and works on 10.5–10.6, but is broken on any later systems. (Which is usually caused by a disaster of libc++ and clangs: say, my 10.6 with libstdc++ has C++23 support, but macOS 12 does not.) Of course, reverse is more common, but nevertheless, for some applications 10.5–10.6 are perfectly usable.