Improvement: Introduce a unique identifier

[henryruhs]

Is your feature request related to a problem? Please describe. It is mostly a theoretical issue as most people will not have multiple device types.

Describe the solution you'd like Properly extend the base usblight class with:

def get_hud_id(light : Any) -> str:
    return str(light.info['path'], sys.stdin.encoding)

This is not a ideal solution as the id changes when light was plugged to another port.

Describe alternatives you've considered An alternative would be to fix the serial numbers on all supported devices, but I guess they don't have it all.

Additional context I do run my software using all_lights() and like to give the user a possibility to filter devices by serial or id. As serial numbers are empty for embrava_blynclight, kuando_busylight and luxafor_flag I used the get_hud_id() solution above. I saw the identifier property in the base class aswell usingt uses the VID and PID but that does not work once you have the same products.

That being said, it would be great to provide a pull request with my suggestion or let's find a better solution.

[JnyJny]

I'm not really sure how you expect me to solve the problem.

If I assign some kind of UUID to a light, how do I ensure that the unplugged light gets the same UUID when it's plugged back in?

[henryruhs]

I didn't expect you to solve that, but was asking if you could add the get_hud_id() helper to the base class!?

[JnyJny]

If you want a light's path value, why not use the path attribute?

from busylight.lights import USBLight

l = USBLight.first_light()
print(l.path)

[henryruhs]

I personally consider a class property like that as internal and would always prefer a public api that is more stable. Additionally I have to use the str() transformation all over the place.

[JnyJny]

It is my understanding that the python convention is to only treat attributes starting with an underscore as private. The USBLight class breaks if the path attribute goes away, so it seems reasonably safe to me. So the remaining objection is you would prefer path to be a str instead of a bytes object?

[henryruhs]

Sure, that would do the job for me aswell...

[JnyJny]

Pushed 076f7dc converting the USBLight.path attribute from a bytes object to a str. Published 0.15.0 to PyPi.

[henryruhs]

Thanks a lot Erik, I very much appreciated your fast release cycles. You could properly do a bump to 1.0.0 soon and continue with semantic versioning from there.

[henryruhs]

@JnyJny Not that I wanna play the CI police but the 0.15.1 pipeline is broken - I hope the 0.15.x releases on pypi are stable enought to be used?