tomba
Add version tags to repo?
Hi! I'm trying to package kmsxx on conda-forge here and it would be important to have version tags on this repo on which to rely for reproducibly downloading sources. Is this possible/planned?
There are no ABI/API stability promises, or any kind of release cycle or such at the moment. I suggest using the git hash as the version, assuming the packaging system supports it. That's what is used e.g. in Buildroot.
A bit side topic, but what's your purpose with the kmsxx package? Are you aware of https://github.com/tomba/pykms ?
Thanks for the feedback! My goal is to package https://github.com/raspberrypi/picamera2 on conda-forge. I think that your pykms repo could be also appropriate, it seems like picamera2 supports both the pure-python implementation and the kms++ bindings. Maybe the kms++ bindings are better for performance reasons? What do you suggest?
Contributing to the dependency hell 😢, there is also https://github.com/raspberrypi/pykms which are another set of bindings to your kms++, AFAIU...
I haven't followed the picamera2 development lately. I remember pointing them to the pure python pykms at some point, though.
As for performance, there's one thing that kms++ does (much) faster, and it's pixel manipulation, i.e. drawing a test pattern. You just can't do that with pure python... However, other than that, I would be surprised if there's a real performance diff. Also, pykms is able to draw test patterns using kms++ native libraries (although it's slightly hacky).
I wasn't aware of https://github.com/raspberrypi/pykms. Looks like it's not bindings, but a packaging project.
I guess one of the main issues which relates to all these is that I don't know how to package kms++'s python bindings so that one could easily install them with e.g. pip. But that's not even in my plans anymore, as I'd rather just use (my) pykms if I need kms in Python.
I guess one of the main issues which relates to all these is that I don't know how to package kms++'s python bindings so that one could easily install them with e.g. pip. But that's not even in my plans anymore, as I'd rather just use (my) pykms if I need kms in Python.
I think the goal of https://github.com/raspberrypi/pykms is precisely this one, i.e. to package the kms++ python bindings to apt and pypi (https://pypi.org/project/rpi-kms/). I would like to build separately the kms++ library itself and the python bindings, I will give it a try.
There are no ABI/API stability promises, or any kind of release cycle or such at the moment. I suggest using the git hash as the version, assuming the packaging system supports it. That's what is used e.g. in Buildroot.
Just to explain a bit where the request comes from, tags are still useful even if there is no ABI/API stability promise. In conda-forge, we have way to explicitly track the ABI stability promise of a library, and ensure that only if the ABI change at every version, the library that builds on top of kmsxx only install the correct version of kmsxx, i.e. the one against with they were built. The main advantage of tags/actual release numbers as opposed to hash checkouts is that versions can be ordered, so the package manager knows which one is the latest version, something that is not possible just with the git hash.
That is the reason why for projects without tags, C++ package managers like vcpkg, conda-forge or conan tipically use the date of the commit to a build a calver-based version, that the package manager can understand and manager.
TL;DR: No problem if you do not want to add tags with version numbers, I wanted just to clarify that the request for tags did not implied any kind of ABI or API stability request.
