hamster-dbus 0.10.0

如何使用

hamster-dbus提供了两个非常不同但相关的功能。

1. hamster_dbus.objects提供了几个可以 用于通过dbu导出服务，这些服务实际上公开了hamster-lib 超过DBU。
2. hamster_dbus.storage包含可以用作有效 可以与中定义的对象通信的hamster-lib的后端 hamster_dbus.objects。这意味着任何支持 hamster-lib可以使用此后端（而不是默认的sqlalchemy后端 例如）使其客户机使用可用的dbus服务 而不是通过sqlalchemy处理后端功能本身。

这两个方面相互独立，但又是对立的两个方面 （类似于服务器和客户端）相同的勋章。

除此之外，还有一个基本的示例dbus服务可执行 （hamster_dbus_service.py）已包含，可用于获取 最小仓鼠dbus服务在短时间内运行。

测试和覆盖范围

hamster-dbus项目致力于提供可维护的、有良好文档记录的 以及测试过的代码。为此，我们提供了一个基本的测试套件 维护并旨在提供90%的覆盖率。 不幸的是，我们目前缺乏对glib/dbus最佳实践的深入了解 关于测试，我们当前基于pytest的解决方案只做了一些 工作。主要问题是为实际的单元提供一个隔离的环境 测试（不是集成测试）。 我们现在处理事情的方式是提供一个专用的设备 在新进程中启动单独的会话总线 测试“上钩”。虽然这种方法大多数时候都有效，但有两种 这里的实际问题（除了不是正确的单元测试之外）：

1. 运行测试套件时可能会出现这样的错误：

   [xcb] Unknown sequence number while processing queue
   [xcb] Most likely this is a multi-threaded client and XInitThreads has not \
       been called
   [xcb] Aborting, sorry about that.
   
   Whilst we do not really understand whats going on this is most likely due
   to the fact that the new spawned session bus process is seperate from the
   actual main look.
   

2. coverage将报告大多数“对象”代码为未测试的，尽管 执行其方法的各种测试。这可能是因为这些方法 由@methoddecorator“阴影”。再说一次，我们缺乏应对的洞察力 现在就用这个。

因此，如果你有任何提示、指针甚至prs可以帮助我们改进 测试设置我们将非常感谢！在那之前我们不能 在ci服务器上自动运行测试套件，这大大限制了我们的qa:（

要在本地运行测试套件，只需在 virtualenv（在make develop之后）：

make test

dbus-monitor "type='signal',sender='org.projecthamster.HamsterDBus',interface='org.projecthamster.HamsterDBus1'

学分

用于呈现此包的工具：

• Cookiecutter
• cookiecutter-pypackage

历史记录

0.10.0（2016-04-26）

• pypi上的第一个版本。