On 7/21/23 11:59, Radosław Piliszek wrote:
On Fri, 21 Jul 2023 at 09:03, Thomas Goirand zigo@debian.org wrote:
Unfortunately I didn’t get any feedback from the company maintaining the nats.py library on supported developer time implemeting the sync client feature, I assume (my view) that they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus) in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).
Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time effort into it.
Would it help if I was packaging NATS in Debian (and therefore, as a consequence, in Ubuntu)? By reading the go.mod, it feels like it has a reasonable amount of dependencies (though I didn't check for the indirect ones), so it feels like doable...
NATS's preferred way of delivery is a single (!) binary offered by the upstream. I guess you could help considerably with minimum effort by repackaging it into a deb so that users going for apt hunting get the upstream NATS.
No way... :)
If I'm to do something, it wont be ugly bianry-only packaging. I was more thinking about doing a *real* packaging work, meaning packaging any missing Go dependency in Debian, and building from source. Otherwise, what value would this bring?
Then it would only boil down to finally packaging the Python library that works well with both OpenStack and NATS but we don't have it yet.
Considering the 400+ Python package I maintain for OpenStack in Debian, that'd be trivial 15 to 30 minutes work for me. :) Packaging a Go app the correct way, without breaking anything else in the whole Go stack in Debian is a way harder (ie: if something needs updating, then all reverse dependencies must be checked and possibly fixed...).
Cheers,
Thomas Goirand (zigo)