Add support for BSD systems

[fohrloop]

Currently (v0.9.1), wakepy checks if platform.system() returns "Linux". All wakepy.Methods have to advertise which system they support.

Task:

• Add support for BSD systems (FreeBSD, OpenBSD, GhostBSD, ...).

[fohrloop]

I'm just about to install GhostBSD 24.04.1 and try to make wakepy work on it.

[fohrloop]

This is what wakepy 0.9.1 gives on GhostBSD:

(venv) fohrloop@fohrloop-ghostbsd ~/c/wakepy (main)> wakepy
/home/fohrloop/code/wakepy/venv/lib/python3.9/site-packages/wakepy/core/platform.py:17: UserWarning: Could not detect current platform! platform.system() returned FreeBSD
  warnings.warn(
                  _
                 | |
 __      __ __ _ | | __ ___  _ __   _   _
 \ \ /\ / // _` || |/ // _ \| '_ \ | | | |
  \ V  V /| (_| ||   <|  __/| |_) || |_| |
   \_/\_/  \__,_||_|\_\\___|| .__/  \__, |
  v.0.9.1                   | |      __/ |
                            |_|     |___/ 
 [x] System will continue running programs
 [ ] Presentation mode is on

    Wakepy could not activate the "keep.running" mode. This might occur because
of a bug or because your current platform is not yet supported or your system is
missing required software.

    Check if there is already a related issue in the issue tracker at
https://github.com/fohrloop/wakepy/issues/ and if not, please create a new one.

    Include the following:
    - wakepy version: 0.9.1
    - Mode: keep.running
    - Python version: 3.9.18 (main, Apr 27 2024, 17:22:44)
[Clang 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g60097
    - Operating system & version: [PLEASE FILL THIS]
    - Desktop Environment & version (if not default): [FILL OR REMOVE THIS LINE]
    - Additional details: [FILL OR REMOVE THIS LINE]

    Thank you!

[fohrloop]

This is what you can see in GhostBSD 24.04.1, CPython 3.9.18:

>>> os.name
'posix'
>>> sys.platform
'freebsd14'
>>> platform.system()
'FreeBSD'
>>> sysconfig.get_platform()
'freebsd-14.0-STABLE-amd64'

How wakepy works currently

• The current "platform" is checked. The current platform is set to WINDOWS, MACOS, LINUX or OTHER
• Each wakepy.Method has a list of supported platforms:

class SomeMethod(Method):
    supported_platforms = (PlatformName.LINUX,)

• When looping over the potential wakepy.Methods to be used to activate a mode, the current platform is compared to the tuple Method.supported_platforms. If current platform is not in that tuple, the method fails.

How wakepy could work in the future

• One problem with the current solution is that there's no pre-defined list of all platforms. The GhostBSD shows itself as "FreeBSD" in platform.system() because it's based on FreeBSD. But in the future it may show itself as "GhostBSD". It's also hard (or impossible) to have a perfect list of all platforms.
• It would therefore be better if the "OTHER" would not fail the platform check, but give "I don't know" as an answer.
• Another problem with the current solution is the need to update every Method definition when a new platform is added. For example, now when FREEBSD is added, should add that to the .supported_platforms of at least KDE and Gnome methods. When there's OPENBSD added, this has to be done again, and all methods will fail on OpenDSD if there's no such platform constant.

Proposed solution (option A)

• Each wakepy.Method would have two lists: supported_platforms and unsupported_platforms
• The platform support step would
  • fail if the current platform is in Method.unsupported_platforms (return False)
  • succeed if the current plarform is in Method.supported_platforms (return True)
  • Say "I don't know" otherwise. (return None)
• The method prioritization step could prioritize all methods with a supported platform the highest, the unknown cases next, and put the unsupported (known to fail) methods last.

With the proposed solution, every wakepy method is tried on each unknown ("OTHER") platform, which is better than failing without trying any methods.

Proposed solution (option B)

• Each wakepy.Method implements its own is_platform_supported method, which takes a platform (current platform) as an input and returns None (unknown) by default, and could also return True (is supported) or False (is not supported).
• There could then be utility functions, like is_unix_like(platform) or is_bsd(platform)

Proposed solution (option C)

• Some way to do

  platform in PlatformSupport((UNIX,), unsupported=(WINDOWS, MACOS))

Here UNIX would be a special platform, which currently would say:

>>> LINUX in PlatformSupport(UNIX)
True
>>> WINDOWS in PlatformSupport(UNIX)
False
>>> OTHER in PlatformSupport(UNIX) # freebsd for example
None

but when UNIX is updated, it would be union of LINUX and BSD, and BSD would be union of all known BSDs, like FREEBSD, OPENBSD.

This way the Methods definitions would hardly ever require update. For example the method for Gnome could be PlatformSupport(UNIX, unsupported=MACOS), and then just the definition of UNIX would be updated in the future.

[fohrloop]

I have been thinking this now for a while, and I think that the Method.supported_platforms may go. The main motivation behind keeping supported_platforms would be the ability to automatically gather lists of Methods for certain platforms for documentation. But there are also downsides:

1. The platforms are many, and it's hard to list them all. One possible list could be CYGWIN, WSL, JUPYTER_NOTEBOOK, ANDROID, FREEBSD, OPENBSD, NETBSD, LINUX, MACOS, WINDOWS10, WINDOWS11, OTHER. When defining Methods, one probably would like to use shortcuts like BSD (=FREEBSD | OPENBSD | NETBSD) or UNIX_LIKE (=LINUX | BSD | MACOS | ANDROID?), and managing this all is not easy. One should also implement different types of operations for these (union, difference, is_in checks, etc.).
2. Wakepy does not really much care about the "platform", but what it cares is which executables or d-bus APIs available and what the desktop environment is, if there is such. Investing a lot to the platform detection logic does not make sense in wakepy at least in this stage (possible that this changes still in the future). Some individual Methods might care a bit about the platform, though.
3. The automatic documentation part is as easy also with a collection of lists, where each list has supported Methods for a platform. For example, there could be a WINDOWS list, UNIX_LIKE (Linux+BSD?) list, etc. And this would be probably approximately as easy to keep in sync as would be the list of supported platforms on each Method class.

What to use instead of Method.supported_platforms?

Perhaps the best would be that each subclass of Method would check the platform compatibility in the Method.caniuse() if that's really required. There can be some helper functions like platform_is_windows() or platform_is_wsl(), etc. to help there. There could be a new PlatformUnsupportedException for communication of platform check specific failure in the caniuse phase.

This way..

1. When support for new platform is added to wakepy, one does not have to go through all the Methods and update some "supported platforms" or "unsupported platforms" list. You would only have to edit the caniuse() the specific Method.
2. There is really just one check for "can I use", and that is in the caniuse() method. This call could also check the used desktop environment, and not just the used OS.

I'll create another ticket for moving the platform check process to be part of the caniuse() check.

[fohrloop]

I tried some BSD systems on instantworkstation.com for getting the platform information in python. I was only successful on OpenBSD 7.4:

• sys.platform: 'openbsd7'
• platform.system 'OpenBSD'

Could not install python (or anything) on NetBSD/DragonflyBSD and did not have time to debug it.

[fohrloop]

Playing around with wakepy on FreeBSD 14.1 + GNOME 42.5

• python -m pytest: all tests pass
• inv test: command fails with FileNotFoundError: [Errno 2] No such file or directory: '/bin/bash' -- should investigate
• wakepy CLI & python API: commands work now (after some modifications in wakepy). I could not make the system to automatically suspend (even with gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout), but I could trigger the automatic idle action (lock session + screensave/blank), and that was successfully prevented.