How to access methods at different object path levels sharing the same interface name? #66

seahawk1986 · 2024-04-23T05:56:11Z

seahawk1986
Apr 23, 2024

Hello,
I am currently evaluating sdbus for a hobby project and stumbled on an problem with the DBus interface of https://github.com/flensrocker/vdr-plugin-dbus2vdr/ - the structure according to d-feet looks like this (all the /Plugins/{plugin_name} objects share the same methods and signatures):

sdbus generates those code snippets for the interfaces:

$ python -m sdbus gen-from-connection --system de.tvdr.vdr /Plugins
from __future__ import annotations

from typing import Any, Dict, List, Tuple

from sdbus import (
    DbusDeprecatedFlag,
    DbusInterfaceCommonAsync,
    DbusNoReplyFlag,
    DbusPropertyConstFlag,
    DbusPropertyEmitsChangeFlag,
    DbusPropertyEmitsInvalidationFlag,
    DbusPropertyExplicitFlag,
    DbusUnprivilegedFlag,
    dbus_method_async,
    dbus_property_async,
    dbus_signal_async,
)


class DeTvdrVdrPluginInterface(
    DbusInterfaceCommonAsync,
    interface_name="de.tvdr.vdr.plugin",
):
    @dbus_method_async(
        result_signature="a(ss)",
    )
    async def list(
        self,
    ) -> List[Tuple[str, str]]:
        raise NotImplementedError


class DeTvdrVdrPluginmanagerInterface(
    DbusInterfaceCommonAsync,
    interface_name="de.tvdr.vdr.pluginmanager",
):
    @dbus_method_async(
        result_signature="a(ss)",
    )
    async def list(
        self,
    ) -> List[Tuple[str, str]]:
        raise NotImplementedError

This is written to a file plugins.py.

$ python -m sdbus gen-from-connection --system de.tvdr.vdr /Plugins/softhddevice
from __future__ import annotations

from typing import Any, Dict, List, Tuple

from sdbus import (
    DbusDeprecatedFlag,
    DbusInterfaceCommonAsync,
    DbusNoReplyFlag,
    DbusPropertyConstFlag,
    DbusPropertyEmitsChangeFlag,
    DbusPropertyEmitsInvalidationFlag,
    DbusPropertyExplicitFlag,
    DbusUnprivilegedFlag,
    dbus_method_async,
    dbus_property_async,
    dbus_signal_async,
)


class DeTvdrVdrPluginInterface(
    DbusInterfaceCommonAsync,
    interface_name="de.tvdr.vdr.plugin",
):
    @dbus_method_async(
        input_signature="ss",
        result_signature="is",
    )
    async def svdrpcommand(
        self,
        command: str,
        option: str,
    ) -> Tuple[int, str]:
        raise NotImplementedError

    @dbus_method_async(
        input_signature="ss",
        result_signature="b",
    )
    async def service(
        self,
        id: str,
        data: str,
    ) -> bool:
        raise NotImplementedError

This is written to a file plugin_interface.py.

Now I want to import those Interfaces - this causes an ValueError:

Python 3.12.2 (main, Feb 25 2024, 16:35:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import plugins
>>> import plugin_interface
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/alexander/projects/python3-yavdrfrontend3/yavdr_frontend/dbus_interfaces/vdr/plugin_interface.py", line 20, in <module>
    class DeTvdrVdrPluginInterface(
  File "/home/alexander/projects/python3-yavdrfrontend3/.venv-3.12/lib/python3.12/site-packages/sdbus/dbus_proxy_async_interface_base.py", line 261, in __new__
    raise ValueError(
ValueError: D-Bus interface of the name 'de.tvdr.vdr.plugin' was already created.

List on both de.tvdr.vdr.plugin and de.tvdr.pluginmanager does the same thing, so I can remove the colliding DeTvdrVdrPluginInterface class from plugins.py for my purposes, but since this was never a problem with other Python dbus libraries (python-dbus, pydbus, dasbus) I am wondering if there is a way around it (or does this interface something not allowed by the DBus specification?).

igo95862 · 2024-04-23T08:34:07Z

igo95862
Apr 23, 2024
Maintainer

Hello @seahawk1986

Having the two different interfaces share the name is a very bad practice. For example, introspection XML under /usr/share/dbus-1/interfaces/ folder is named by their interface names so those two interfaces will conflict.

or does this interface something not allowed by the DBus specification

There is nothing that prohibits it directly but I want to enforce good practices.

As a workaround you can merge those two interfaces in a single class:

from __future__ import annotations

from typing import Any, Dict, List, Tuple

from sdbus import (
    DbusDeprecatedFlag,
    DbusInterfaceCommonAsync,
    DbusNoReplyFlag,
    DbusPropertyConstFlag,
    DbusPropertyEmitsChangeFlag,
    DbusPropertyEmitsInvalidationFlag,
    DbusPropertyExplicitFlag,
    DbusUnprivilegedFlag,
    dbus_method_async,
    dbus_property_async,
    dbus_signal_async,
)


class DeTvdrVdrPluginInterface(
    DbusInterfaceCommonAsync,
    interface_name="de.tvdr.vdr.plugin",
):
    @dbus_method_async(
        input_signature="ss",
        result_signature="is",
    )
    async def svdrpcommand(
        self,
        command: str,
        option: str,
    ) -> Tuple[int, str]:
        raise NotImplementedError

    @dbus_method_async(
        input_signature="ss",
        result_signature="b",
    )
    async def service(
        self,
        id: str,
        data: str,
    ) -> bool:
        raise NotImplementedError

    @dbus_method_async(
        result_signature="a(ss)",
    )
    async def list(
        self,
    ) -> List[Tuple[str, str]]:
        raise NotImplementedError

2 replies

seahawk1986 Apr 24, 2024
Author

Thank you.

Another thing I noticed was that sdbus can generate invalid method names that are protected Python keywords, e.g. a DBus Method with the name Del() is transformed into async def del(self, ...) - while linters catch those very quickly and you can change the name and override the method_name in the decorator, I wonder if if would be helpful to improve the name mangling or output a warning when creating the code for the interface class.

igo95862 Apr 24, 2024
Maintainer

My current policy is that the output of the code generator must be inspected before running. There is even a warning in the documentation not to send it to compile().

I do plan to add a command line options to override a specific interface method name so that you can have a reproducible output.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

How to access methods at different object path levels sharing the same interface name? #66

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 2 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

How to access methods at different object path levels sharing the same interface name? #66

Uh oh!

seahawk1986 Apr 23, 2024

Replies: 1 comment · 2 replies

Uh oh!

igo95862 Apr 23, 2024 Maintainer

Uh oh!

seahawk1986 Apr 24, 2024 Author

Uh oh!

igo95862 Apr 24, 2024 Maintainer

seahawk1986
Apr 23, 2024

Replies: 1 comment 2 replies

igo95862
Apr 23, 2024
Maintainer

seahawk1986 Apr 24, 2024
Author

igo95862 Apr 24, 2024
Maintainer