Hacker News Reader

Comment by arthurcolle | Hacker News Reader

Can someone elucidate why he is so against "his" code being used in this project?

He says early in the thread:

> If users experiencing issues with the ambee library in this package, they will knock on my door. And I'm not willing to support that or accept that burden. Especially as I don't see a good repacking reason in this case.

I mean, yes, but then when the NixOS folks offer something like:

requiring users to explicitly set config.ambee.acceptThatThisPackageIsNotSupportedByUpstreamDevelopersAndIWillGoToNixpkgsToReportAnyIssues = true to be able to install the package, or they would get an error that would make it even clearer. Would that be enough for you?

the author replies just:

I feel like I'm starting to be on repeat now. Please don't add any of my stuff to this project.

The author may well have plausible reasons but it was obvious from the overly curt tone he wasn't going to treat the discussion constructively

Perhaps forking 'fully', and rebranding the fork, could be another option. That might help redirect the support burden downstream.

But when suggested alternatives to resolve that issue, he simply ignores it and states “sorry, this is my wish” with no further clarification.

The whole chain is a guessing game trying to figure out what the real issue is (and in the end, it’s not even found — the author randomly finds an alternative he likes)

That's an extremely valid concern, but one that seems easily addressed via an FAQ.

"I'm running into some issues with ambee..."

"First, make sure you aren't using the version in nixpkgs. I do not support that distribution and cannot help you."

So ye olde "I don't like distros packaging my FOSS project because they won't do it exactly the way I want."

Seems that he wants pypi and pip to be the exclusive distribution mechanisms for his project. He wants to avoid handling bugs that come from his project being packaged through other means.

He misunderstands how nixos works and suggests that Home Assistant will be able to install his package via pip on nixos.

> He wants to avoid handling bugs that come from his project being packaged through other means.

From his conduct in the thread this seems a red herring. The nixos devs have proposed a selection of reasonable solutions to avoid any support burden on his part, all of which he's rejected outright.

I’m not sure why there are scare quotes around “his”, the code is the author’s property, it’s just they’ve granted a license for it to be used by anyone.

The scarequotes are certainly inappropriate unless it's CC0 licensed, but you do point out that he's explicitly granted a license "for it to be used by anyone". Which seems... of some relevance here.

Python ambee is a simple client library for a proprietary sass iot service. I guess they want to control exactly how their users are using their service.

Yet the author is an admin on the HomeAssistant community forum, one of only 6. Presumably his other contributions to the project justify those privileges, and he did not shut down the passive-aggressive thread some nixOs folks started there, it was another admin (the founder of HomeAssistant).

This sucks for nixOs, but it looks like community incompatibility means they won’t be able to support HomeAssistant at all.

Some context: Frenck is a core developer on the Home Assistant project, and was hired by Nabu Casa (the company the project's founder founded to try to create a sustainable funding source via adding some optional value-add services) to develop for Home Assistant full time.

If instead of packing these separately, the home assistant nixpkg for home assistant simply downloaded all the required dependencies from PyPi, and verified them against a maintained list of checksums as part of the nixpkg (for reproducibility), then frenck probably would not object to that, since the last I knew the some of the official home assistant docker images do preinstall the requirements for the majority of plugins like that.

I'm suspect frenck's real concern comes from any possibility of modifications in the packaged version, combined with any possibility of nix allowing home assistant to be used with a version that is not an exact match of what home assistant specifies.

Alternatively If this could be packages as some form of home-assistant sub-package that was guaranteed to always match the PyPi version specified for home assistant exactly, without any mixing and matching, it would likely allay his concerns. Unfortunately he has not spelled out his concerns fully, so I cannot know for sure. I also have no idea if this is at all feasible in the nix packaging system.

> If instead of packing these separately, the home assistant nixpkg for home assistant simply downloaded all the required dependencies from PyPi, and verified them against a maintained list of checksums as part of the nixpkg (for reproducibility), then frenck probably would not object to that

From what I can tell the Home assistant core team doesn't not want to deal with any other installation variants than their own supported ones. Their user base consists of a lot of technical tinkering people (hobbyists, electricians, etc) but those who don't necessarily have Linux sysadmin skill's. So you could say they are skilled enough to get themselves in any of a hundred different configuration scenario's that would then need to be debugged by the HA developers for each support ticket. For a developer knowing the installation environment is at least sane is a great help.

That said, Home assistant does lend a lot of its growth to open source contributions, collaboration and being free software. If it was not as open in the beginning it might not have gathered enough attention to grow its current size. Cutting off developments in other directions like this to me feels against what FOSS stands for.

If users experiencing issues with the ambee library in this package, they will knock on my door. And I'm not willing to support that or accept that burden. Especially as I don't see a good repacking reason in this case.

https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86...

I am not the author so I can only speculate. He's anticipating that they will be distributing an out-of-date package and it's simply another place that has to be synchronized. He's saying that there isn't actually a need to host it elsewhere as it can be installed via pip through pypy (his preferred host) which will have up-to-date code. He doesn't want to get bug reports for outdated code.

This is incredibly legitimate reason. Could these repacking be replaced with some type of just proxy/clone that is still the original source?

NixOS doesn’t work like that apparently. The point is to be reproducible.

Honestly sounds like they just cannot have his project or anything that depends on it.

Luckily that ambee code looks trivial to duplicate.

the author of the lib pushed the code by a PR to Home Assistant, a project that is packaged by multiple distribution, including ubuntu, fedora, arch and more, all of which will repackage the library. The author should ask for removal from HA, not going to all packager for all distro requiring to be removed

The author is a core contributor of HA, so he will have a strong opinion about removing his own package I think.

I don't have any experience of nix packaging, but I work on a couple of programs when Debian applied some broken patches while packaging, then "we" (upstream) get the bug reports. It's annoying as we don't have any way of fixing it, just have to tell users to uninstall the Debian version.

I mean this very famously happened with OpenSSL - Debian started producing the same keypairs for everyone!

Apparently not, since the author couldn't/didn't want to either.

Users will contact the author for support, but users are getting the software indirectly via a packager, which means a) there might be changes from the packager b) they might be getting an older version that appears to be the "latest" and c) they don't have a way to install a modified version provided by the author to test out a fix in the same way that they installed their current version.

(It's true that with nixpkgs these problems are much more solvable than in basically any other distro, but the risk is stil there.)

This is the case with literally every piece of software packaged for linux, it seems that nix is just the first place to attempt to package this. The project looks to only be a week old anyhow.

The package author lays out the reasons in his comments

The reason is the concern that users will confuse issues with the project with issues with how the project is distributed in Nixpkgs. He doesn't want to have to support nixpkgs.

There are likely multiple root causes. The whole space of issue management around libraries and applications using those libraries is a horrible and abusive mess. In my experience, between an application using a library and a library users will target whichever is easiest; not most applicable. Plus, most opensource user support is a fucking chore (you'd need to pay me for these days) that's unsustainable.

Another cause is likely the cost of nixpkgs contributions themselves. Personally, I no longer contribute to nixpkgs because even for tiny changes the process is ridiculously expensive. That's not including the cost of getting up to speed with nix/nixpkgs and the, often, highly opinionated packaging.

nixpkgs needs to be broken up into multiple independently distributable packages.

Reply on news.ycombinator.com