fohrloop / wakepy Goto Github PK
View Code? Open in Web Editor NEWCross-platform keep-awake with python
License: MIT License
Cross-platform keep-awake with python
License: MIT License
Affected versions: at least 0.6.0, 0.7.0, 0.7.1
The D-Bus method used on Linux uses org.freedesktop.ScreenSaver
interface, Inhibit
method to take an inhibitor lock. This causes the screen not to lock at all, even if using keepawake(keep_screen_awake=False)
(wakepy <=0.6.0) or keep.running()
(wakepy >=0.7.0). This is known and mentioned in documentation.
Use some another method on Linux with keep.running()
, which only inhibits suspend (and does not inhibit screesaver / screen lock).
Wakepy current is said to support windows and linux. But how about WSL? Does it work currently, and if not, what method should be used on WSL?
Ubutu Unity 22.04 locks and turns off the screen (and forgets the screen brightness, which it always does on my iMac when the screen got turned off) after the set timeout even after running and not cancelling wakepy -s
.
The "Suspend" system menu entry does nothing.
I'm running Fedora 36 on a Lenovo Legion 7, and I ran the simple code:
from wakepy import set_keepawake, unset_keepawake
set_keepawake()
Yet my computer still goes to sleep after a few minutes. What's happening?
The following program (I used pyinstaller to make an executable) immediately crashes - see below.
from wakepy import keep
import time
with keep.running() as k:
while True:
time.sleep(10)
Stack backtrace:
D:\PyCharm Projects\keepAwake\dist>keepawake.exe
Traceback (most recent call last):
File "main.py", line 4, in
File "contextlib.py", line 117, in enter
File "wakepy\keep.py", line 87, in running
File "wakepy\keep.py", line 45, in temporary_solution_for_using_old_functions_with_new_api
File "wakepy_deprecated_init.py", line 37, in get_function
File "importlib_init_.py", line 127, in import_module
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 984, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'wakepy._deprecated._windows'
[12692] Failed to execute script 'main' due to unhandled exception!
The current Linux implementation relies on the systemctl
command. However, this is not always available.
It is possible to send D-Bus messages directly with dbus-send
. Could it be used in wakepy?
I had my battery running low on my laptop with Linux Mint 21.1 with Cinnamon.
I set the lock and waited.
When the battery reached 2% the computer shut down as if I had pressed "Shut Down" even though the setting what to do when the battery dies was set to "Do Nothing".
After starting up again the option "suspend" was missing from the power menu, pressing the power button (set to suspend) did nothing and systemctl suspend
errored out. Everything returned to normal after running wakepi.unset_keepawake()
in Python3, even though I set the lock with
import wakepy, time
with wakepy.keepawake(True):
while True:
time.sleep(3)
print('Another 3 seconds!')
Think about how prioritization and selecting used Methods should work. What kind of API there should be? Would using list of strings be good, or should user need to use list of Method classes?
This is detailed summary from all the messages from below. Will be updating this to reflect the latest view of how this is going to be implemented; no need to read all the messages below as much of it is obsolete and not relevant.
mode = keep.running(
dont_use=['G'], priority_order = [{'A', 'B'}, '*', {'E', 'F'}]
)
def running(only_use:list[str], dont_use:list[str], priority_order:list[str|set[str]]) -> Mode:
methods_for_mode = get_methods_for_mode(ModeName.KEEP_RUNNING)
selected_methods = select_methods(methods_for_mode, only_use=only_use, dont_use=dont_use)
return Mode(methods=selected_methods, priority_order=priority_order)
Mode.__init__
, check the priority order against the selected methods. (PR #91)# methods: List[MethodCls]
# priority_order: List[str | Set[str]]
prioritized_methods: List[MethodCls] = get_prioritized_methods(methods, priority_order)
# let's say we have
priority_order = [{'A', 'B'}, '*', {'E', 'F'}]
methods = [A, B, C, D, E, F]
# (1) could make this
methods = [{A, B}, {C, D}, {E, F}]
# (2) could make this
methods = [[B, A], [C, D], [F, E]]
# (3) could make this
methods = [B, A, C, D, F, E]
Splitting this work from #69 into its own ticket.
As there are not yet any Methods which utilize a heartbeat, this can be postponed until some release after the 0.8.0.
The current implementation simply raises NotImplementedError
on linux if none of the existing methods (jeepney, dbus-python, systemd) can be used. It would be nicer for the user to be able to control what happens if using keepawake is not possible.
Currently, if someone would like to continue when setting keepawake is not possible, something like this must be used:
Option A
try:
from wakepy import keepawake
except NotImplementedError:
# Make a mock for replacing keepawake..
from contextlib import contextmanager
@contextmanager
def keepawake(*args, **kwargs):
yield
... # some code
with keepawake():
# do something
Option B
try:
from wakepy import set_keepawake, unset_keepawake
except NotImplementedError:
# Make mocks for replacing set_keepawake and unset_keepawake..
set_keepawake = lambda:None
unset_keepawake = lambda:None
... # some code
set_keepawake()
# do something
unset_keepawake()
It would be nicer if the user could decide what occurs when:
(a) A keepawake method fails (dbus address not found, etc..) --> on_method_failure
(b) Setting keepawake fails completely --> on_failure
Then, code could look something like this:
from wakepy import keepawake
with keepawake(on_failure='warn'):
# do something
This is much cleaner code and nicer to the user. Suggested options for on_failure
and on_method_failure
could be
So, on linux, with multiple methods defined: keepawake(method_linux=('jeepney', 'systemd')):
would, in absense of dbus address and sudo rights, by default:
logger.info
logger.info
KeepAwakeError
and tell that jeepney cannot be used because DBUS_SESSION_BUS_ADDRESS
is not set and systemd cannot be used because sudo rights are missing.Hello,
I have a python program packed with pyinstaller which uses wakepy. After packing for windows 10 .exe program is halted when wakepy with keep.running()
is called. Have you tested it with pyinstaller?
Wakepy has one dependency on linux: jeepney, which provides dbus support. There are yet no D-Bus free methods on linux, but there is a ticket (#64) for searching for such methods on GNOME.
It could be possible to either:
A) Make just the necessities install by default and have special options for adding something.
B) Make everything install by default and have special options for leaving something out
Consider making the jeepney dependency optional. This means,
pip install wakepy
would install only wakepy and nothing else, ever. Trying to use wakepy when non-DBus based methods are not available, would not succeed:
with keep.presenting() as k:
if not k.success:
print('Failed setting keepawake')
Installing:
pip install wakepy[dbus]
would install the supported dbus package (jeepney).
Pros:
Cons:
Keep installing a dbus python package by default when running
pip install wakepy
Users can opt-out from the dbus with
pip install wakepy --no-deps
Pros:
Cons:
--no-deps
in requirements.txt (or setup.py?); Users wanting to opt-out need to install wakepy separately.pip install wakepy[some-extra]
Ideally, pip install wakepy
would install wakepy with DBus and there would be another extras which would remove the dbus python package dependency:
pip install wakepy[no-dbus]
This would be super handy as only experienced users might want to drop out this dependency. Unfortunately this does not seem to be supported by pip.
Pros:
Cons:
Taken from a SO answer: Use environment variables to determine the D-Bus need. It could be either
NODBUS=1
or making use of the DBUS_SESSION_BUS_ADDRESS
which should be set in most of the cases if D-Bus is available (if that is set, install D-Bus dependencies automatically, otherwise not). The example had a setup.py
file like this:
import os
from setuptools import setup
install_requires_base = [...]
setup(
...
install_requires=install_requires_base + ([] if os.getenv('NODBUS', False) else ['jeepney']),
...
)
I'm not sure if this would be possible with pyproject.toml or not.
Pros:
Cons:
Make
pip install wakepy
to install the default set of dependencies. Jeepney (or some other dbus python package) would be automatically included on systems like linux. This is because an average user should not have to think more than pip install wakepy
. Behind the scenes this would install some wakepy-vanilla
which is the base version and then for example jeepney
for dbus. In the future, this default set could evolve, but users could rely on the fact that anything needed for the typical use case is installed automaticlaly. This would not be same as installing "ALL" possible extras, like some move-mouse-package
(does not exist). Then, power users could then use
pip install wakepy-vanilla
For installing the vanilla version, or even using wakepy-vanilla[dbus]
for just dbus extras.
Motivation
pip install wakepy
did not install a required package for their system and that when setting the wakelock, there was no exceptions and they have to dig out the documentation to see why their system is still going to sleep.Pros:
Cons:
Edit: Renamed alternatives (A, B, C, D) to (A1, B1, B2, B3). Added alternative B4.
Hi, wouldn't it make sense to treat the disabled sleep mode as context, which could be returned by set_keepawake()
and used for automatic unset_keepawake()
?
Finalize the ModeController class, which should have following interface:
class ModeController:
def __init__(self, call_processor: CallProcessor):
...
def activate(
self,
method_classes: list[Type[Method]],
methods_priority: Optional[MethodsPriorityOrder] = None,
) -> ActivationResult:
...
def deactivate(self):
...
It looks like the code for keeping the screen awake is backwards. See the details for caffinate:
-d Create an assertion to prevent the display from sleeping
And the code (ARGS is -d -u
):
if keep_screen_awake:
global _process
_process = Popen([COMMAND], stdin=PIPE, stdout=PIPE)
else:
_process = Popen([COMMAND] + ARGS, stdin=PIPE, stdout=PIPE)
It's sending -d -u if we do NOT want to keep the screen awake. I'll send a PR.
When trying to load this module on Linux system with systemd, the module fail with the following trace:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.8/subprocess.py", line 411, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.8/subprocess.py", line 489, in run
with Popen(*popenargs, **kwargs) as process:
File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'pidof systemd'
The line subprocess.check_output('pidof systemd')
should be replace by subprocess.check_output(['pidof','systemd'])
Trying to open wakepy.readthedocs.io gives 404 error
Consider for example readthedocs.org.
There was previously (wakepy v.0.7.1) an exception thrown on older versions (< 3.9) of Python because of unsupported type annotations (#50). It would be handy to have automatic tests for the __main__.py
/ cli part, too.
With using they toy examples on my windows 10 machine, I get an invalid keyword argument for the ActivationResult seen here:
Line 220 in 5792c00
Checking the signature for this class, it is clear that init does not accept this:
wakepy/wakepy/core/activationresult.py
Line 193 in 5792c00
Create basic tox tests and add CI (github actions?).
Go through the docs and update them.
PART 1
PART 2
Related PRs
Hey! Trying this on macOS and Python 3.9 I got:
Traceback (most recent call last):
File "/Users/michaelkennedy/Desktop/wakepy/example_app/macos/macos_app.py", line 18, in <module>
wakepy.unset_keepawake()
File "/Users/michaelkennedy/Desktop/wakepy/wakepy/_darwin.py", line 38, in unset_keepawake
_process.stdin.write(BREAK)
TypeError: a bytes-like object is required, not 'str'
I'll submit a PR to fix this in a moment.
Splitting this work from #69 into its own ticket.
main
branch (unreleased) has too much responsibility. Make the Method class to be just for definitions of the Method. This will be used for subclassing.activate_using(method, ...)
function could be used to activate a "mode" with just a Method class; no need for Mode. This is going to be a helper function in #69.def activate_using(methodcls: MethodCls, ...) -> tuple[MethodUsageResult, HeartBeat|None]:
method = methodcls()
if check_platform_support(method) is False:
return MethodUsageResult(failure_stage=PLATFORM_SUPPORT), None
if check_requirements(method) is False:
return MethodUsageResult(failure_stage=REQUIREMENTS), None
entered = try_enter_mode(method)
heartbeat_started = try_heartbeat(method)
if not entered or not heartbeat_started:
return MethodUsageResult(failure_stage=ACTIVATION), None
if heartbeat_started:
heartbeat = Heartbeat(method)
heartbeat.start()
return MethodUsageResult(), heartbeat
Some parts of wakepy, namely the contents of wakepy._deprecated
subpackage, are deprecated in 0.7.0. Remove these.
On linux, there are multiple methods which could be used:
These all are tried in order. It would be nicer for the user if the method could be selected when setting the keepawake. An iterable of methods could also be accepted.
Possible syntax:
with keepawake(method_linux='jeepney'):
...
or
with keepawake(method_linux=('jeepney', 'systemd')):
...
etc.
Create general D-Bus interface class + jeepney implementation of that class.
The class should have the functionality needed to do the things wakepy does currently, including:
bus = DBus.get_bus('session')
retval = bus.call_method(bus_name, object_path, interface, method, signature)
Could someone test this on macOS? What happens if wakepy process is killed while lock is set? Is the lock released?
It might be interesting to have multiprocessing-supporting approach that uses a counter under the hood; for each set_keepawake()
call there should be unset_keepawake()
and for example if one calls set_keepawake()
three times, the unset_keepawake()
should be called three times before it would actually bet unset. In current implementation, if there were three long running processes (2hrs, 30hrs and 30hrs), and all of them would be using unset_keepawake()
, PC would sleep soon after 2hrs.
Another possible implementation would be to use mouse movement or pressing a key, but these typically need some (or a lot) of other dependencies.
When checking out a branch and pressing tab, git shows a list of branches and tags sorted alphabetically. This puts all the tags starting with a digit to the front of everything, like this:
(venv) ~/code/wakepy$ git checkout
0.2.0 0.5.0 FETCH_HEAD ORIG_HEAD
0.3.0 0.6.0 HEAD origin/HEAD
0.3.1 0.7.0 issue-52-activationresult origin/master
0.4.2 0.7.1 master
It is not uncommon to have tens or 100+ tags in a project. Perhaps better to have them in the end (start with v). This seems to be a common practice, used for example in matplotlib, scipy, pandas, numpy, pydantic and rich (but not everyone, like pip)
Task:
[major].[minor].[patch]
to v[major].[minor].[patch]
Add Method for keep.presenting mode which uses the org.freedesktop.ScreenSaver (D-Bus). The implementation should subclass the wakepy.core.Method.
This is basically a ticket to myself, and is continuation of work in the PR #51, which left the main branch in an unfinished and bit messy state.
Mode.__exit__
and add ModeExit
exception which can be used to exit the mode with statement block. (PR #72)Mode
(for supporting running wakepy in multiple threads) (PR #71)work done on this ticket but not relevant anymore
The current implementation has three systems:
These are all actually just directly platform.system().lower()
.
Might be better the change the name to be "platform" as python might be running on WSL or Cygwin on Windows..? Not yet sure if these two can be supported but at least is should be possible to detect that wakepy is running on WSL/Cygwin.
Task:
Splitting this work from #69 into its own ticket.
def activate(methods: list[MethodCls], ...) -> tuple[ActivationResult, HeartBeat|None]:
prioritized_methods = prioritize_methods(methods)
result = ActivationResult()
for method in prioritized_methods:
methodresult, heartbeat = activate_using(method, ...)
result.add(methodresult)
if result.success:
break
return result, heartbeat
The cli.py needs some attention before 0.8.0 release. In particular, the deprecation message needs to be removed (and all the deprecated things).
It would be nice to have non-DBus based on methods available on GNOME. This would make D-Bus (and the python package jeepney) an optional dependency on GNOME.
Task:
If has been thought that wakepy 0.7.0+ would look like this:
from wakepy import keep
with keep.running() as k:
if not k.success:
# warn user
# do something
where k
is an ActivationResult
object.
But would it be nicer if the API was
with keep.running() as k:
if not k.active:
# warn user
# do something
I.e. the word was "active" instead of "success"? In addition, the return value from Mode.__enter__()
could be the Mode (self), and not an ActivationResult? Thinking about how well this reads:
from wakepy import keep
# create a mode instance
mode = keep.running()
with mode as m:
if not m.active:
# warn user
# do something
if m
is the mode (instance of Mode
) , this reads pretty well. Not so sure if the m
is a ActivationResult
instance. The full activation result could be put into .res
or .result
attribute of Mode.
A (keepawake) mode is activated by trying a set of different methods. It might be nice to be able to set a maximum number of used methods, so for example:
with keep.running(max_methods=None) as k:
...
could try to use all of the methods in keep.running.methods
, but
with keep.running(max_methods=1) as k:
...
would stop at the first successful method.
I've written a small proof of concept:
from contextlib import contextmanager
import dbus
import time
@contextmanager
def inhibit(application, reason):
bus = dbus.SessionBus()
obj = bus.get_object('org.freedesktop.PowerManagement.Inhibit',
'/org/freedesktop/PowerManagement/Inhibit')
inhibitMethod = obj.get_dbus_method('Inhibit', 'org.freedesktop.PowerManagement.Inhibit')
unInhibitMethod = obj.get_dbus_method('UnInhibit', 'org.freedesktop.PowerManagement.Inhibit')
cookie = inhibitMethod(application, reason)
try:
yield cookie
finally:
unInhibitMethod(cookie)
print('Starting…')
with inhibit('TestApp', 'TestReason'):
time.sleep(10)
print('Done!')
The title says it all: Create function or functions for deactivating a mode.
The function signature could be
def deactivate(method:Method, heartbeat:Heartbeat):
...
Add Methods for keep.presenting and keep.running modes which use the caffeinate (MacOS). The implementation should subclass the wakepy.core.Method.
There should be no print calls other than the ones for CLI usage. Replace print calls with logging.
[Errno 2] No such file or directory: 'caffeinate -d'
I believe I can fix it. PR will follow
Add Methods for keep.presenting and keep.running modes which use the SetThreadExecutionState. The implementation should subclass the wakepy.core.Method.
The modes in wakepy current 0.8.0dev return a ActivationResult
object, like this:
with keep.running() as k:
if not k.success:
print('failed to set keepawake')
here k
is an ActivationResult
object.
Edit: Marking Communication with the thread which switches the mode out of scope. In scope: Just the data storage and retrieval mechanism for ActivationResult
There are multiple possible ways to set a keepawake / inhibitor on linux:
Q1) If a system has dbus-daemon running, does it also can dbus-send executable available? Could dbus-send replace jeepney solution? Or can jeepney be used as dbus solution in a situation where dbus-send executable is not available?
Q2) If a system does have systemd (systemctl command) available, does it automatically mean that dbus is available? Could systemd solution be dropped in favor of a dbus solution? Does the systemctl command use dbus internally?
Q3) In which situations dbus-python would be needed? (Related: #32 )
Edit: Added dbus-python
Hej,
The issue originally stems from another project where I am importing wakepy and it is causing all sorts of issues in readthedocs generation. I was able to reproduce the issue locally though with just wakepy.
Presently running an Ubuntu 20.04.4 LTS VM on WSL.
While I did get dbus-x11 installed and running, it seems $DBUS_SESSION_BUS_ADDRESS isn't set and that is causing problems.
I'm not sure what else is missing but maybe it could be caught by expanding the except after the import dbus
$ sudo apt-get install dbus-x11
Reading package lists... Done
Building dependency tree
Reading state information... Done
dbus-x11 is already the newest version (1.12.16-2ubuntu2.3).
0 upgraded, 0 newly installed, 0 to remove and 136 not upgraded.
$ service dbus status
* dbus is running
$ pip install dbus-python pydbus
Requirement already satisfied: dbus-python in /usr/lib/python3/dist-packages (1.2.16)
Requirement already satisfied: pydbus in /home/riley/.local/lib/python3.8/site-packages (0.6.0)
riley@OHENP-PW012RVH0:/mnt/c/SourceCode/PythonDriver$ python3
Python 3.8.10 (default, Jun 22 2022, 20:18:18)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import wakepy
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/riley/.local/lib/python3.8/site-packages/wakepy/__init__.py", line 35, in <module>
from ._linux import set_keepawake, unset_keepawake
File "/home/riley/.local/lib/python3.8/site-packages/wakepy/_linux/__init__.py", line 17, in <module>
my_module = import_module(f".{module}", f"wakepy._linux")
File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "/home/riley/.local/lib/python3.8/site-packages/wakepy/_linux/_jeepney_dbus.py", line 26, in <module>
connection = open_dbus_connection(bus="SESSION")
File "/home/riley/.local/lib/python3.8/site-packages/jeepney/io/blocking.py", line 341, in open_dbus_connection
bus_addr = get_bus(bus)
File "/home/riley/.local/lib/python3.8/site-packages/jeepney/bus.py", line 53, in get_bus
return find_session_bus()
File "/home/riley/.local/lib/python3.8/site-packages/jeepney/bus.py", line 42, in find_session_bus
addr = os.environ['DBUS_SESSION_BUS_ADDRESS']
File "/usr/lib/python3.8/os.py", line 675, in __getitem__
raise KeyError(key) from None
KeyError: 'DBUS_SESSION_BUS_ADDRESS'
Hi, thanks for this :)
While super simple, it's always good to have a cross-platform package, especially when it's source code is easy to read and understand.
One thing that could be a factor in decisions on whether to use this is how force killing a process (Task manager in windows, kill in Linux etc) will affect it?
I've tested on Windows, and it seems that killing the python process successfully removes the lock (makes sense that SetThreadExecutionState would die with the process).
But is this the same for linux / mac?
Regardless of result it could be good to document in the readme.
When calling
from wakepy import set_keepawake, unset_keepawake
user will get:
KeyError: 'DBUS_SESSION_BUS_ADDRESS'
tox.ini
with following contents[tox]
env_list = py{38,39,310,311}
minversion = 4.4.11
[testenv]
description = run the tests with pytest
package = wheel
wheel_build_env = .pkg
deps =
pytest>=6
commands =
pytest {tty:--color=yes} {posargs}
set_keepawake
:# tests/test_wakepy.py
def test_import_set_and_unset_keeepawake():
from wakepy import set_keepawake, unset_keepawake
niko@niko-ubuntu-home:~/tmp/repos/wakepy$ tox -e py310
.pkg: _optional_hooks> python /home/niko/venvs/wakepy/lib/python3.10/site-packages/pyproject_api/_backend.py True setuptools.build_meta __legacy__
.pkg: get_requires_for_build_wheel> python /home/niko/venvs/wakepy/lib/python3.10/site-packages/pyproject_api/_backend.py True setuptools.build_meta __legacy__
.pkg: build_wheel> python /home/niko/venvs/wakepy/lib/python3.10/site-packages/pyproject_api/_backend.py True setuptools.build_meta __legacy__
py310: install_package> python -I -m pip install --force-reinstall --no-deps /home/niko/tmp/repos/wakepy/.tox/.tmp/package/10/wakepy-0.6.0-py3-none-any.whl
py310: commands[0]> pytest --color=yes
=================================================================== test session starts ====================================================================
platform linux -- Python 3.10.6, pytest-7.2.2, pluggy-1.0.0
cachedir: .tox/py310/.pytest_cache
rootdir: /home/niko/tmp/repos/wakepy
collected 1 item
tests/test_wakepy.py F [100%]
========================================================================= FAILURES =========================================================================
___________________________________________________________ test_import_set_and_unset_keeepawake ___________________________________________________________
def test_import_set_and_unset_keeepawake():
> from wakepy import set_keepawake, unset_keepawake
tests/test_wakepy.py:2:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
.tox/py310/lib/python3.10/site-packages/wakepy/__init__.py:35: in <module>
from ._linux import set_keepawake, unset_keepawake
.tox/py310/lib/python3.10/site-packages/wakepy/_linux/__init__.py:17: in <module>
my_module = import_module(f".{module}", f"wakepy._linux")
/usr/lib/python3.10/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
.tox/py310/lib/python3.10/site-packages/wakepy/_linux/_jeepney_dbus.py:26: in <module>
connection = open_dbus_connection(bus="SESSION")
.tox/py310/lib/python3.10/site-packages/jeepney/io/blocking.py:341: in open_dbus_connection
bus_addr = get_bus(bus)
.tox/py310/lib/python3.10/site-packages/jeepney/bus.py:53: in get_bus
return find_session_bus()
.tox/py310/lib/python3.10/site-packages/jeepney/bus.py:42: in find_session_bus
addr = os.environ['DBUS_SESSION_BUS_ADDRESS']
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = environ({'HOME': '/home/niko', 'LANG': 'en_US.UTF-8', 'TERM': 'xterm-256color', 'PATH': '/home/niko/tmp/repos/wakepy/....NS': '156', 'LINES': '26', 'PYTEST_CURRENT_TEST': 'tests/test_wakepy.py::test_import_set_and_unset_keeepawake (call)'})
key = 'DBUS_SESSION_BUS_ADDRESS'
def __getitem__(self, key):
try:
value = self._data[self.encodekey(key)]
except KeyError:
# raise KeyError with the original key value
> raise KeyError(key) from None
E KeyError: 'DBUS_SESSION_BUS_ADDRESS'
/usr/lib/python3.10/os.py:679: KeyError
================================================================= short test summary info ==================================================================
FAILED tests/test_wakepy.py::test_import_set_and_unset_keeepawake - KeyError: 'DBUS_SESSION_BUS_ADDRESS'
==================================================================== 1 failed in 0.08s =====================================================================
py310: exit 1 (0.33 seconds) /home/niko/tmp/repos/wakepy> pytest --color=yes pid=8462
.pkg: _exit> python /home/niko/venvs/wakepy/lib/python3.10/site-packages/pyproject_api/_backend.py True setuptools.build_meta __legacy__
py310: FAIL code 1 (1.18=setup[0.84]+cmd[0.33] seconds)
evaluation failed :( (1.22 seconds)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.