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

[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: gorakhargosh/watchdog#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.