Closed robbiet480 closed 8 years ago
hi @robbiet480 , thx for your contribution. If you think this is stable, we may consider to distribute it part of NUT, under the scripts/go directory
@aquette I would want to add full tests first before doing that but I would be happy to have it distributed with NUT after that!
@robbiet480 : great! and I'm fully in favor of having tests for all things. Please keep me updated.
@aquette I think this is definitely nice to have, and I do like the MIT license, but I really don't think we should mix GPL and MIT licensed code in the same repository. (Not all distros have Debian's flexibility on marking which licenses apply to a package.) We already split out jNut for other technical reasons, so having language bindings in separate repositories is not unprecedented.
@clepple @aquette Actually, I realized an even better reason to keep it out of scripts directory: Go won't like the code being in a subdirectory without a lot of hacks.
I also agree that mixing licenses isn't always a great idea.
On another note, when will I see this change go live on either http://new.networkupstools.org/projects.html or http://networkupstools.org/projects.html? The readme made it sound like buildbot should automatically deploy it to new.
but I don't see it. It won't go to networkupstools.org until the next full release though, correct? It works with protocol 1.2 so if it could go live before the next release (since it seems the release schedule is very spread out) that would be great but no rush :smile:
BTW, the reason I built the library is to add NUT support to telegraf so I can store UPS stats in InfluxDB for pretty display with Grafana. Hope to submit a PR to telegraf soon with my work.
@robbiet480 The reply-by-email thing seems to be broken [edit: fixed now], so to paraphrase: we do have to trigger the website rebuilds by hand at the moment, and they should end up at http://new.networkupstools.org. However, something else broke (maybe permissions?) and I am debugging that now.
If nothing else, we should probably update the news page between NUT releases.
Also, the protocol numbers shouldn't change often (ever again, IMHO - comparing version numbers is fragile) because old servers should respond with a well-defined CMD-NOT-SUPPORTED
per the protocol definition. Clients can try a new command to see if it is supported, and fall back if there is a less-efficient way to accomplish the same query.
https://github.com/robbiet480/go.nut