pyudev 0.16.1

A libudev binding

http://pyudev.readthedocs.org

pyudev is a LGPL licensed, pure Python binding for libudev, the device and hardware management and information library for Linux. It supports almost all libudev functionality. You can enumerate devices, query device properties and attributes or monitor devices, including asynchronous monitoring with threads, or within the event loops of Qt, Glib or wxPython.

The binding supports CPython 2 (2.6 or newer) and 3 (3.1 or newer), and PyPy 1.5 or newer. It is tested against udev 151 or newer, earlier versions of udev as found on dated Linux systems may work, but are not officially supported.

Usage

Usage of pyudev is quite simply thanks to the power of the underlying udev library. Getting the labels of all partitions just takes a few lines:

>>> import pyudev
>>> context = pyudev.Context()
>>> for device in context.list_devices(subsystem='block', DEVTYPE='partition'):
...     print(device.get('ID_FS_LABEL', 'unlabeled partition'))
...
boot
swap
system

The website provides a detailed user guide and a complete API reference.

Support

Please ask questions about pyudev on the mailing list at [e-mail]. To join this list, send a mail to [e-mail] and reply to the confirmation email.

Please report issues to the issue tracker, but respect the following guidelines:

• Check that the issue has not already been reported.

• Check that the issue is not already fixed in the master branch.

• Open issues with clear title and a detailed description in grammatically correct, complete sentences.

• Include the Python version and the udev version (see udevadm --version) in the description of your issue.

Development

The source code is hosted on GitHub:

git clone git://github.com/lunaryorn/pyudev.git

Please fork the repository and send pull requests with your fixes or new features, but respect the following guidelines:

• Read how to properly contribute to open source projects on GitHub.

• Understand the branching model.

• Use a topic branch based on the develop branch to easily amend a pull request later, if necessary.

• Write good commit messages.

• Squash commits on the topic branch before opening a pull request.

• Respect PEP 8 (use pep8 to check your coding style compliance).

• Add unit tests if possible (refer to the testsuite documentation).

• Add API documentation in docstrings.

• Open a pull request that relates to but one subject with a clear title and description in grammatically correct, complete sentences.