Using libusb-package is a problem for system packaging

[dvzrv]

Hi! I would like to package this project for Arch Linux.
Unfortunately it requires libusb-package, which vendors a version of libusb. However, on Linux we already provide libusb and it does not make sense to vendor these shared libraries within the context of a python package.

The change introduced in ce05b14 is problematic as it would require downstream distributions to package a vendored libusb that can not be used by anything else.

It would be very awesome if the import of the module could be made optional.

[dvzrv]

@flit I have created a PR (#1332) that makes the use of libusb_package optional and falls back to usb.core if it can not use it.
This would at least allow distributions (because frankly, no Linux distribution will want to use libusb-package, as there is already pyusb interfacing with libusb) to simply remove the requirement for libusb-package in setup.py and plainly rely on pyusb.
There should probably be a note about this though.

There were instances of guards against failing imports of usb.core and usb.util in some of the files, which were not in others.
I didn't dig much deeper and am not sure whether they are really required.

While working on the pull request I realized that libusb-package is solely used for the find() call and pyusb is used anyways. Is the overhead of shipping your own version of libusb in the context of a python package really worth it?

[jjakob]

Patch to replace all uses of libusb_package with usb.core and remove the libusb_package dependency
https://github.com/jjakob/gentoo-overlay/blob/master/dev-python/pyocd/files/0001-Use-pyusb-instead-of-libusb_package-remove-libusb-pa.patch