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.
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.
(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?)
Nobody does this, as this is completely unreasonable thing to expect.
It is not uncommon to see them request changes to the bumped library to fix any issues they have noticed.
What do you mean by that, why shouldn't they include it?
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...
The person proposing the Nix package is a Home assistant developer afaik, so that would be weird.
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.
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.
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.
> Seems he's just being unreasonable for the sake of it tbh; I can't see any logical reasoning behind it all.I agree.
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!
The only entitlement form the nixos devs has been using a right which Frenck explicitly chose to provide when licensing his software.
In the end, the will have to fork it, and probably maintain a fork of HM, since he is relicensing it to disallow repackaging.