Providing the package as a wheel

[crisbal]

Hi,

Do you know if it would be possible to provide wheels (manylinux one even https://github.com/pypa/manylinux ) for this package?

The project can be built as a wheel just fine with python -m build and auditwheel repair evdev-1.6.0-cp39-cp39-linux_x86_64.whl works as well.

But my gut feeling tells me that this might not be that easy, especially because the project depends on Kernel headers during the build process and the resulting wheel would then become kernel dependent?

Could someone please confirm this for me?

Thanks for your help :)

[jonasclaes]

The input_event definition in the Linux kernel should be pretty stable, which would make it possible to build this package and distribute it as a wheel. However, if the input_event definition ever changes, then we would not be able to distribute it as a wheel anymore, unless we do a version bump and specify that a minimum kernel version is needed for the version bumped package.

[ehfd]

@jonasclaes @gvalkov @sezanzeb @KarsMulder

Hi! I would like to clarify the minimum kernel version this package requires. I'm trying to create a Conda package to integrate into my application.

It seems that when I'm building on a kernel header without the UI_GET_SYSNAME ioctl, which is under 3.15, the wheel build succeeds, but the following error occurs when trying to import the library.

Traceback (most recent call last):
  File "/opt/build/conda-bld/evdev_1714211781387/test_tmp/run_test.py", line 2, in <module>
    import evdev
  File "/opt/build/conda-bld/evdev_1714211781387/_test_env_placehold/lib/python3.11/site-packages/evdev/__init__.py", line 5, in <module>
    from evdev.device import DeviceInfo, InputDevice, AbsInfo, EvdevError
  File "/opt/build/conda-bld/evdev_1714211781387/_test_env_placehold_pl/lib/python3.11/site-packages/evdev/device.py", line 14, in <module>
    from evdev.eventio import EventIO, EvdevError
  File "/opt/build/conda-bld/evdev_1714211781387/_test_env_placehold_pl/lib/python3.11/site-packages/evdev/eventio.py", line 6, in <module>
    from evdev import _input, _uinput, ecodes, util
ImportError: /opt/build/conda-bld/evdev_1714211781387/_test_env__pl/lib/python3.11/site-packages/evdev/_uinput.cpython-311-x86_64-linux-gnu.so: undefined symbol: UI_GET_SYSNAME

The kernel header available next in line (other than v3.10.0 which corresponds to CentOS 7) is v4.18.0. Does this mean that the minimum kernel header is v3.15.0 for UI_GET_SYSNAME, and thus I need to use v4.18.0 for Conda, or not?

[KarsMulder]

Hello! I am here to clean up the mess I created.

Pull request #218 should make this package work even on kernels that don't have UI_GET_SYSNAME defined.

[ehfd]

Will it work on CentOS 6 (kernel 2.6.32, without input-event-codes.h) as well as CentOS 7 (kernel 3.10.0) then?

Would like a v1.7.1 release ASAP then, as Conda only accepts official releases.

[KarsMulder]

Even after fixing the UI_GET_SYSNAME issue, python-evdev still doesn't work on CentOS 7 due to an unrelated issue. I have created pull request #219 to fix that unrelated issue. After merging #218 and #219, python-evdev should have at least some sort of functionality on CentOS 7 (though I haven't tested more than "can I create an UInput device and send a key").

CentOS 6 has been EOL since November 30th, 2020. I have not tested functionality on that operating system.

[ehfd]

Great, thank you!

[sezanzeb]

Some sort of github pipeline would be nice to have. And I think someone (Maybe me, but I'm a tad busy with life right now) should check and improve the automated tests, I think they aren't working.

[sezanzeb]

Hello! I am here to clean up the mess I created.

Well, I'm glad I'm not the only one anymore who broke something in python-evdev. Though I did some pretty weird stuff back then.

[ehfd]

The pipeline is simple and good. It just needs to test some more complex capabilities that is easy to break in more OSes.

Looking forward to the merge and .1 release (which earlier is better for me).

[sezanzeb]

They are merged. Can you please check if it builds correctly for you now?

[ehfd]

On it.

[ehfd]

All good. @KarsMulder @sezanzeb Even the Conda version of CentOS 6 imports. Thanks for the great job. I will merge the Conda recipe when the new release arrives.

[ehfd]

Looking for feedback from @gvalkov on the .1 release.

[ehfd]

It seems that in Ubuntu 22.04 (Python 3.10.6, pip 22.0.2) but not Ubuntu 20.04 (Python 3.8) or Ubuntu 24.04 (Python 3.12), the following error consistently shows during a pip install, preventing the installation of v1.7.0.

2024-05-03T20:56:20.0737383Z #29 5.790 Collecting evdev>=1.3
2024-05-03T20:56:20.2321150Z #29 5.798   Downloading evdev-1.7.0.tar.gz (30 kB)
2024-05-03T20:56:20.3215582Z #29 6.038   Installing build dependencies: started
2024-05-03T20:56:22.7371082Z #29 8.454   Installing build dependencies: finished with status 'done'
2024-05-03T20:56:22.8917765Z #29 8.458   Getting requirements to build wheel: started
2024-05-03T20:56:22.9385665Z #29 8.655   Getting requirements to build wheel: finished with status 'done'
2024-05-03T20:56:23.1531200Z #29 8.870   Installing backend dependencies: started
2024-05-03T20:56:24.7865178Z #29 10.50   Installing backend dependencies: finished with status 'done'
2024-05-03T20:56:24.9410070Z #29 10.51   Preparing metadata (pyproject.toml): started
2024-05-03T20:56:24.9991993Z #29 10.72   Preparing metadata (pyproject.toml): finished with status 'done'
2024-05-03T20:56:25.1868048Z #29 10.72   WARNING: Generating metadata for package evdev produced metadata for project name unknown. Fix your #egg=evdev fragments.
2024-05-03T20:56:25.1873134Z #29 10.72 Discarding https://files.pythonhosted.org/packages/f3/0c/c87b141250a650ee53d4e9957e905b17c144cda6dc4187cbe89a641a1b34/evdev-1.7.0.tar.gz#sha256=95bd2a1e0c6ce2cd7a2ecc6e6cd9736ff794b3ad5cb54d81d8cbc2e414d0b870 (from https://pypi.org/simple/evdev/) (requires-python:>=3.6): Requested unknown from https://files.pythonhosted.org/packages/f3/0c/c87b141250a650ee53d4e9957e905b17c144cda6dc4187cbe89a641a1b34/evdev-1.7.0.tar.gz#sha256=95bd2a1e0c6ce2cd7a2ecc6e6cd9736ff794b3ad5cb54d81d8cbc2e414d0b870 (from pynput->selkies-gstreamer==0.0.0.dev0) has inconsistent name: filename has 'evdev', but metadata has 'unknown'
2024-05-03T20:56:25.1876474Z #29 10.74   Downloading evdev-1.6.1.tar.gz (26 kB)
2024-05-03T20:56:25.1876930Z #29 10.75   Preparing metadata (setup.py): started
2024-05-03T20:56:25.2292907Z #29 10.95   Preparing metadata (setup.py): finished with status 'done'

[gvalkov]

Hello and sorry for the terrible delay. I've just uploaded 1.7.1 to pypi.

I have the best intention to soon provide binary wheels in a manner similar to how psycopg2 does it (i.e. pip install evdev[binary]).

Thanks to everyone involved in this.

[gvalkov]

Hi @ehfd,

Just gave it a quick try and can confirm that it doesn't work with the system-python and system pip. It seems to work when it is installed in a virtualenv:

$ python3 -m venv test
$ test/bin/pip install evdev
$ test/bin/pip freeze
evdev==1.7.1
$ test/bin/python3 -c 'import sys, setuptools, pip; print(sys.version, setuptools.__version__, pip.__version__, sep=", ")'
3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0], 59.6.0, 22.0.2

Upgrading pip also seems to solve it.

My gut feeling is that this is something Debian/Ubuntu related.

[gvalkov]

Version 1.7.1 is now also available as a binary wheel, through the evdev-binary package. They're compiled in the manylinux_2_28 image against kernel 4.18. At the moment it's all done locally, but at some point I'll move it to a Github workflow...

[ehfd]

Great. The conda-forge feedstock will be compiled with CentOS 7 (manylinux_2_17/2014) on x64, aarch64, ppc64le when it gets approved.

[ehfd]

https://github.com/conda-forge/evdev-feedstock https://anaconda.org/conda-forge/evdev

We have a Conda feedstock. Please tell me if any of you'd like to be added as a maintainer.

[ehfd]

@gvalkov You should have received an invitation to conda-forge.