Make the use of libusb-package optional

[dvzrv]

pyocd/probe/*:
Attempt to import libusb-package's find() function, else fall back to using pyusb's find() function.
This allows to use pyusb by just removing the project's requirement on libusb-package, as python-pyusb and libusb
packaging go hand-in-hand on Linux distributions.

Related to #1331

[elfmimi]

Any idea for promoting users to install libusb upon the user doing pip install pyocd ? @dvzrv

[dvzrv]

Any idea for promoting users to install libusb upon the user doing pip install pyocd ? @dvzrv

Not from the top of my head. In systems packaging this is easy due to system-wide dependency management.
When installing via the python ecosystem this is of course very limited. Maybe the user can at least be warned about missing libusb in that context? I don't know what discovery facilities pyusb has for that. Libusb itself could be queried via pkgconfig integration though.

[flit]

@elfmimi That's basically what libusb-package was intended to solve. 😄 Users no longer need to worry about installing libusb.

@dvzrv For distro packages, I totally understand the requirement to use the distro-installed libusb. It only makes sense.

How to handle distros was actually something under consideration when designing libusb-package, at least at a high level. The distro version of libusb-package should return the distro libusb. (And if the user separately installs libusb-package from PyPI, the user gets the prebuilt wheel containing libusb.) This is the path I'd much prefer to take.

libusb-package supports being installed without a contained copy of libusb, a so-called "empty install". In this case, it will always fall back to asking for the system libusb via ctypes.find_library().

The part that's missing is a way to force an empty install. But is this even needed? How do you generate a distro package of a Python package? If you can just take the libusb-package source from the repo, then there's nothing additional needed—it will be an empty install by default.

A more advanced option would be to install a symlink to the distro libusb .so in order to explicitly pin libusb-package to that libusb version.

[elfmimi]

I know. I know, kind of, I asked for it.

[dvzrv]

The part that's missing is a way to force an empty install. But is this even needed?

Yes, we do not want to rely on precompiled shared libraries, but on system libraries that can be built reproducibly and be used by more than one application.

How do you generate a distro package of a Python package? If you can just take the libusb-package source from the repo, then there's nothing additional needed—it will be an empty install by default.

We usually go the PEP517 route these days. Packaging guidelines for python on Arch Linux can be found in the wiki.
Can you elaborate what you mean by "empty install"?

[diggit]

Can you elaborate what you mean by "empty install"?

When I tried to install libusb-package using PKGBUIULD according to linked wiki page, resulting package did not carry any pre-built shared library and pyocd was happy. Here is PKGBUILD I tested with.

It would mean new dependency for python-pyocd package, which would have to go directly into community repo. Despite that, maintaining wrapper package looks like least intrusive solution.

[dvzrv]

As there is only limited time to deal with packages, I wonder what there is left to do with this PR.
From a distribution standpoint it makes no sense at all to package libusb-package, as with this patch we can directly make use of pyusb and everything just works.

Operating systems which require the bundling of libusb to make this work can still rely on libusb-package if they want to (this PR just falls back to pyusb if it libusb-package is not available).

@flit This means libusb-package could become a dependency only for specific operating systems (e.g. windows and/or macOS). However, at this point I am still asking myself why this is needed at all. Have you tried to reach out to https://github.com/pyusb/pyusb, as that project has been around for a long time and libusb-package looks like duplicated effort if pyusb could just add wheels bundling libusb.

It would mean new dependency for python-pyocd package, which would have to go directly into community repo. Despite that, maintaining wrapper package looks like least intrusive solution.

@diggit But this is precisely the point. I maintain over 700 packages for Arch Linux. Why would I want to package yet another wrapper around libusb if there is already pyusb?

[dvzrv]

@flit I have rebased on latest default branch. Please have a look

[a-detiste]

please