`ModuleNotFoundError: No module named '_curses'` when running `maestral activity`

[frozenpandaman]

Seems the bug in #533 & #591 has popped up again after updating to 1.6.3:

$ maestral activity                                              
Traceback (most recent call last):
  File "Contents/Resources/Support/Python/Resources/lib/python3.10/runpy.py", line 196, in _run_module_as_main
  File "Contents/Resources/Support/Python/Resources/lib/python3.10/runpy.py", line 86, in _run_code
  File "Contents/Resources/app/maestral_cocoa/__main__.py", line 41, in <module>
  File "Contents/Resources/app/maestral_cocoa/__main__.py", line 36, in freeze_support_cli
  File "Contents/Resources/app_packages/click/core.py", line 1130, in __call__
  File "Contents/Resources/app_packages/click/core.py", line 1055, in main
  File "Contents/Resources/app_packages/click/core.py", line 1657, in invoke
  File "Contents/Resources/app_packages/click/core.py", line 1404, in invoke
  File "Contents/Resources/app_packages/click/core.py", line 760, in invoke
  File "Contents/Resources/app_packages/maestral/cli/common.py", line 107, in wrapper
  File "Contents/Resources/app_packages/click/core.py", line 760, in invoke
  File "Contents/Resources/app_packages/maestral/cli/common.py", line 32, in wrapper
  File "Contents/Resources/app_packages/maestral/cli/cli_info.py", line 85, in activity
  File "Contents/Resources/Support/Python/Resources/lib/python3.10/curses/__init__.py", line 13, in <module>
ModuleNotFoundError: No module named '_curses'

The workaround in that earlier issue still works.

Using Python 3.9.13 on macOS 12.3.1, Maestral v1.6.3 installed via Homebrew.

[samschott]

Damn, apparently moving the app bundle to Python 3.10 was a bit premature.

The problem is: the macOS app bundle, whether installed through Homebrew or otherwise, come with its own CPython library. It turns out that the Python 3.10 library which we are using does not currently link against libcurses, therefore the missing module error and the missing functionality.

Fixing this will be annoying because we are using the Python build from the BeeWare project at https://github.com/beeware/Python-Apple-support. Essentially, we could either revert to using their Python 3.9 build or move to their newest build of Python 3.10 which again supports curses (a patch which I submitted). However, the latter can only be used on macOS 10.15 and higher. This means we either take a step back, or leave some users behind...

[frozenpandaman]

Dang, annoying! Thanks for looking into this. How much of a hassle would it be (if even possible at all) to distribute two separate Mac versions, one using Python 3.10 for 10.15+ users, and another with Python 3.9 for users on older OSes? Or – is there any downside on still using Python 3.9 for the time being?

[slifty]

Just to have some relevant factoids for the discussion / decision:

1. 10.14 / Mojave has been EOL since October 2021: it is no longer maintained by Apple and it no longer receives security updates from them. It came out in September 2018 (so almost 4 years ago)
2. It looks like around 97% of MacOS homebrew users in the past 30 days are on 10.15+

3. If you want a longer window, 93% in the past year

I know I'm just in the peanut gallery but I do think it's OK to drop support for operating systems that are no longer considered LTS by their vendors.

As an aside: @samschott you might want to consider developing a project policy that provides guidelines for when you're not planning to support a given OS (for instance you might target support for LTS versions) -- that way users can predict their own required update cycles and it can free you up from concern when of version thrash when upgrading things like python versions / etc.

[samschott]

@slifty, thanks for the info, this is quite useful! I am lacking this insight from GitHub releases downloads and don't collect any analytics whatsoever which might be helpful here. Essentially, I am flying blind. At least now I have some info about the homebrew subset of users.

Also, I never expected this project to become something which requires a "project policy" or any form of release planning. I started it way before I would have called myself a software engineer. However, it might be time to give users a better way to plan ahead.

[slifty]

@samschott Absolutely! Also just to make sure it didn't come off wrong, that policy idea was NOT meant as a critique (and it may not even be a useful idea here of course!) I have found it useful on some FOSS projects I work on to be able to say "ah yes, if { the version of NodeJS } is not supported by the {Node} team then we won't support it either." <-- maybe more useful for you as the dev than anything else, honestly.

Outside of the land of Brew I did find these stats too which say 85% are on 10.15+ / everything Catalina and above is lumped together as "Catalina". I don't know how accurate they are or exactly how they are sourced, but it's another data point.

I think they're using web agent data, which apparently stopped distinguishing between MacOS versions at 10.15 -- which is to say it's useful for THIS but won't be useful for future decisions.

[philippgerard]

I just ran into this, too.

Any idea when this will be resolved, @samschott ? I think it's good to cut out some dead wood, in the best tradition of Apple, in case you're still contemplating what to do with <10.15 users.

[samschott]

Soon :)