As EUropean living in a different country for work, is not that easy at all. Try to do your taxes in Swedish or German or French.. Or try to have a social life with people that while could speak English will probably switch to their own language when in more than 2-3 person. Yes of course you can learn the language, but dont think you can be proficient in a couple of year, especially if working 40h/week, and still you will be proficient in a country at max

> will probably switch to their own language when in more than 2-3 person.

That's just rude and why would you want to socialise with such people. I had some great experiences and even when I was the only person not speaking the local language, everyone spoke English in my presence. There is plenty of people that have standards and if you cannot find them at a given time, just focus on something else.

Isn't it a bit much to expect everyone to accommodate you? What if some don't speak English?

It could be rude but not necessarily. Context matters

> That's just rude and why would you want to socialise with such people.

Well, tough luck. Welcome to Germany. Living and working in Germany? Learn German. This is the treatment I’ve got and frankly, that’s okay!

Been there, done that, it takes some work but it's not such a hurdle.

> a traditionally distro wouldn't even bother packaging any of this stuff or engage at all.

unfortunately the library author made a PR to Home Assistant, a program that is packaged in many distro; all those distro will add his package. see https://github.com/home-assistant/core/pull/51645

Is home-assistant packaged in any traditional distro like Debian or Fedora? I didn't think so.

So long as everyone is supposed to just grab some docker container or OS image from the home-assistent people, the traditional distros that should back up NixOS here won't even be looped in.

There's literally a comment in there about Fedora having packaged it.

I'm glad to be wrong! Does fedora package all the python libs separately, or allow the deps to be vendored in this case?

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.

> You're entitled to nothing when authors write FOSS. They provide it as-is. Take it or leave it. No one is obligated to take support harassment.

the author of the lib literally pushed it to Home Assistant, so he gave it to a relatively famous project that is present in a lot of distro and Snapstore. Pushing to such project is a guarantee that your code will be repackaged. He could say it was a misunderstanding and require to be remove from HA, but to go to a project that uses the project that you PR your code into? eh. We have licensing for this reason and I am quite sure if frenck had choose the correct license/limitation from the beginning, it would have never been accepted into HA and this whole problem would have been avoided

> Tons of FOSS projects do not support alternative distributions. In fact, implicitly, virtually no one does. Most authors publish software with the expectation you'll use their distribution channels.

I don't think this is true, and the fact that already author's libs had been already packaged in Gentoo, Fedora and possibly more distro (and he said he will request to remove them) show how quickly alternative and well used channel can and will pick them up if not specified in your license. Especially if the project you are contributing is ALREADY packaged in different disto.

source: https://github.com/home-assistant/core/pull/51645

> Pinning every Python dependency instead of fetching HEAD is how you get local control and security!

yes it is? they make sure the user get a specific version that is (hopefully) vetted and know as working properly; this is much safer than pulling HEAD for a 3th party repo. As long as the libs are updated regularly and when security issue are found, I see no problem with this approach

> he has the right to transitively make Home Assistant un-packagable on NixOS?

Pretty sure a custom license is not compatible with the Apache 2 license of "Home Assistant"; also as the code is in use by a third party, the author should not be able to retroactively change license, only next releases. Probably will be forked or removed depending on the specific of the case and of the code.

> they make sure the user get a specific version that is (hopefully) vetted and know as working properly

This is exactly what nixpkgs maintainers do, using more reliable and explicit tools than the likes of pip. A significant effort is made to enable tests on as many packages as possible, meaning that when you get a package from nixpkgs, it has been tested against the exact dependency chain (down to the libc) it is being shipped to you with. If tests fail, issues are investigated and solved.

This is a far stronger guarantee than you get from almost any other installation method.

No they don't. Debian etc don't trigger a full rebuild every time they add a patch to libxml2.