Comment by 63
5 years ago
Is there greater context here that helps explain what's going on? Reading the comments in the thread didn't clarify much for me as someone unfamiliar with NixOS, their apparently unique Python packaging scheme, and Home Assistant.
It sounds like Home Assistant by default pulls the (EDIT: Home assistant specified, not latest) version of the package from PyPI at runtime and loads it dynamically.
The point of NixOS is reproducible builds, that is if you build a given nix environment you will always get the same code. Dynamically pulling from PyPI at runtime defeats that.
The author doesn't want any way of downloading the code other than getting "the supported version" from PyPI, as they don't want to deal with support requests for issues that are fixed later. They are likely worried that packaged versions will become stale, and users will expect support for specific versions, which they are unprepared to offer.
I think the offers from NixOS of having to enable config flags to get this enabled which make it clear it's not supported by upstream should be fair. Part of open source is that others are free to modify your code, and if you have a problem with that you're not really ok with the idea of open source.
Yeah I really wouldn't want to use anything that dynamically pulls a package from PyPI at runtime, because I don't trust this guy not to add a vulnerability to the code at a later point in time.
Okay, so ... I know someone might, but really who will audit any of his existing code?
(Sure, that's slightly different than identifying such an auto-update point and then trying to do a supply-chain attack. But do maintainers look at what they package? In how much detail?)
5 replies →
> It sounds like Home Assistant by default pulls the latest version of the package from PyPI at runtime and loads it dynamically.
Package versions are recorded in component manifests so it will not default to the latest version, someone has to make a code change and PR on homeassistant to update the version. And they are collected in a requirements file for every HA release[0]. So it should not be hard to automate that if needed whenever the HA Nix package gets updated to ensure the latest used version of ambee package is included.
[0] https://github.com/home-assistant/core/blob/dev/requirements...
His project has zero issues created. It's a pretty small and simple library.
Why would users report to his project when installing Home Assistant? That's not usually how it works and Home Assistant has a lot of other dependencies.
This is not true. Home-assistant does not pull the latest version of packages (for integrations) from pypi. They are tracked in manifest files: https://github.com/home-assistant/core/blob/ae28e4934f6d1cdb...
This sounds like NixOS is not ready to handle this scenario and they are bulldozing the issue to get it included.
NixOS is quite ready to handle home-assistant but did not yet package every python package that it could depend on. That is just taking a bit more time and will be eventually done. Until then you should take a quick look at your logs if something is broken/not working and you should easily find which package is missing. If you need help with that you can always jump on the NixOS matrix channel and people will help you with that.
> ... and they are bulldozing the issue to get it included.
What do you mean by that, why shouldn't they include it?
I think the greater context is that the Home Assistant developers are somewhat hostile to people running, and especially packaging, their software outside of their own supported methods (which are Docker containers or their own full OS). It's somewhat understandable as it creates a support burden for them, but especially given the enthusiast nature of the community this doesn't seem like a smart decision. There's been some outrage in the community about the developers deprecating platforms before.
> I think the greater context is that the Home Assistant developers are somewhat hostile to people running, and especially packaging, their software outside of their own supported methods..
The person proposing the Nix package is a Home assistant developer afaik, so that would be weird.
Well, Home Assistant is a large project with lots of contributors, so it's not surprising that its developers don't have a singular opinion. However, this is the impression I get from the official announcements and other interactions I've seen on GitHub.
Another incident was when they deprecated/unsupported installing it on a generic Linux install last year, which they had to (somewhat) back down from after community outrage.
Yes, fabaff is a bigger home-assistant contributor to my knowledge and started to help out packaging a lot of the missing python libraries for NixOS.
He just doesn't want anything of his included in nixpkgs because he doesn't want to deal with anyone opening Github issues against his repos if there happen to be build / installation issues that are coming from some kind of failure in the nixpkgs install / build process.
That's speculative on his part (noone has opened any issues with him, neither coming from nixos nor from any other repackaging).
The nixos guys also offered various proposals to him to completely avoid any support burden on his part, all of which he roundly rejected.
Seems he's just being unreasonable for the sake of it tbh; I can't see any logical reasoning behind it all.
Not sure why I'm being downvoted for what he explicitly lays out from the link above:
> Seems he's just being unreasonable for the sake of it tbh; I can't see any logical reasoning behind it all.
I agree.
> That's speculative on his part (noone has opened any issues with him, neither coming from nixos nor from any other repackaging).
Which is the whole point of acting on it before it happens...
It's crazy the amount of entitlement I see toward open-source developers. You don't like his stance, then fork it and support it yourself. You are already lucky to have a good base to work on, you shouldn't even be entitled to that!
2 replies →
Also they offered various options to appease the author including code forking and the author rejected them all. Basically the team exhausted all of their options to make this author happy but the author seem not to understand the reality of FOSS. This author shouldn't be in the FOSS if the author is going to roadblock every options despite his licensing explicitly allows including the codes.
Agreed. If he wants to be stubborn like this he just should change his licensing so it can't be included anywhere else upstream and that would put an end to it.