Apologies, I did not put that security comment in the correct spot. Opening and running subprocesses through Python are a security threat, not the parsing of output.

I agree that 3 is likely not possible--I wasn't even considering the use of pyusb because I wanted to avoid having to change much of your current source code. Like how pre-commit has a mypy-mirror project that wraps around mypy to make it compatible with pre-commit.

I'd also like to see how feasible it'd be to call uhubctl natively. This would require some changes to your source code, but nothing notably difficult (likely returning output instead of printing it as you are now).

After some experimentation on my end, I have determined that running uhubctl natively from python is possible, but impossible with the current design of the program. I was able to successfully compile uhubctl with Python wrappers and got it to run via main() from Python a few times; however, I occasionally ran into a few issues like the notoriously helpful "segmentation fault (core dumped)".

If we decide to follow this approach, I may need some help with some C-related details to do it right. Regardless, this approach is the most intensive as it would likely require exposing custom functions in uhubctl to make it compatible as an API, not just a standalone program. What these would look like or their requirements are unknowns but can be determined as development progresses.

Overall, I still favor this approach (albeit to a lesser degree lol) as it seems to be the most "holistic". I dislike using subprocesses, especially in a situation like this, as I view them to be "hacky". However, I have no issue using them if the alternative is a truckload of work.

Jules

I understand that you don't like to spawn external process.
That said, using python wrapper seems like really bad idea in this particular case, because it would want to pull full libusb library in.

In terms of portability, spawning external process is safest: you can write python script which will not pull any module dependencies (except for import subprocess, which is standard anyway), and will only require that uhubctl executable is present on the PATH - thats all you need. And if uhubctl is not available in PATH, you can complain back to the user asking them to install missing tool. Any other approach is much more fragile and demanding.

Note that all projects in this list: https://github.com/mvp/uhubctl#notable-projects-using-uhubctl are using uhubctl as external process, and it seems to work for everyone just fine.

Also, even if we implement -j, that will make parsing output quite a bit easier, but it will not remove a need for external process.

Sure, why don't we move forward with running this through subprocesses then. Are you leaning towards implementing -j then, or do you want me to move forward with creating a custom parser?

That would be most beneficial, yes. You know the output of this project more than anyone.

Because I don't see this library benefitting from maintaining any object states, I believe structuring this similar to numpy will likely be the best approach (mostly global functions implementing standalone code).

So, for example:

import uhubctl
# Examples for commonly-implemented functions
hub_count = uhubctl.get_hub_count()
compatible_hubs = uhubctl.get_compatible_hubs()
# Example of the main implementation function
uhubctl.exec(action=..., location=..., level=..., vendor=..., ports=...)
...