python3Packages.ambee: init at 0.2.1

[fabaff]

Motivation for this change

Python client for Ambee API

https://github.com/frenck/python-ambee

• Related Home Assistant change: Add Ambee integration home-assistant/core#51645
• Target Home Assistant release: 2021.7.0

ToDo:

• Update component-packages
• Enable tests in Home Assistant

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[r-rmcgibbo]

Result of nixpkgs-review pr 126326 at 7c91525 run on aarch64-linux 1

2 packages built successfully:

• python38Packages.ambee
• python39Packages.ambee

---

Result of nixpkgs-review pr 126326 at 7c91525 run on x86_64-linux 1

2 packages built successfully:

• python38Packages.ambee
• python39Packages.ambee

[frenck]

As the author of the package that is being re-packaged here. I'm against it being repacked into here.
While licensing wise I cannot stop you, I do hope you can honor my request.

Thank you for considering respecting the author's wishes.

[fabaff]

@frenck, what's the reason you are against it?

It's a Home Assistant dependency and as a dependency it has to be present otherwise users would not be able to use the ambee integration.

[frenck]

It's a Home Assistant dependency and as a dependency it has to be present otherwise users would not be able to use the ambee integration.

That is not true. It is a pure Python package, Home Assistant will just fetch it from PyPi using pip.

@frenck, what's the reason you are against it?

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.

[mweinelt]

It's a Home Assistant dependency and as a dependency it has to be present otherwise users would not be able to use the ambee integration.

That is not true. It is a pure Python package, Home Assistant will just fetch it from PyPi using pip.

That is sadly not true and probably a large part of the misunderstanding here.

Given that Nix packaging results in immutable output paths, home-assistant simply cannot go around and modify its site-packages by itself. Users need to opt-in to the components at build time and for that to be possible we need to package their individual dependencies into nixpkgs.

[frenck]

In that case you are shipping an broken Home Assistant version.

Which I definitely don't want to be part of.

Please remove this package, including all my other packages.

Thank for respecting my wishes as the author of the source.

[lukegb]

In that case you are shipping an broken Home Assistant version.

Which I definitely don't want to be part of.

Please remove this package, including all my other packages.

Thank for respecting my wishes as the author of the source.

Hi! I'd like to understand your concerns a little better:

• Would you be happier if we were using the release tarballs/wheels from your published PyPi releases instead?
• Have you had support load from users of NixOS as a result of this that we haven't seen? That would certainly be unfortunate and is not our intent, but it would be good to know about now.
• Would you be happier if we forked your upstream source to provide our own, or provided a similar Python package with an identical API that we can use as a drop-in replacement?
• Are you aware of similar efforts to package Home Assistant in a manner suitable for other Linux distros, such as Gentoo, that also include your packages (by necessity)? Do you have similar concerns there?

I'm also a little anxious that this thread has the potential to get heated quite quickly, so if you have the time and are willing to it might be worth setting up a quick Jitsi Meet to talk about this. Failing that, maybe we should pull this off into a separate issue thread so we can discuss there instead.

[frenck]

My wishes are above, please do not repack my code into this project. Please respect that request. It is a fairly simple request, nothing heated about it. I have no intention of spending time in this project.

Thanks.

[lukegb]

My wishes are above, please respect those. It is a fairly simple request, nothing heated about it. I have no intention of spending time in this project.

Thanks.

Thanks for your time. In a similar spirit, I'll spend no further time responding to this request. I'll leave it up to other people to decide what they would like to do.

[frenck]

Thanks, @lukegb nevertheless thanks for your extended questions. 👍

Edit: All alright back at PC.

Would you be happier if we were using the release tarballs/wheels from your published PyPi releases instead?

My request wasn't related to how it got the source, I don't see how that question is relevant.

Have you had support load from users of NixOS as a result of this that we haven't seen? That would certainly be unfortunate and is not our intent, but it would be good to know about now.

This package is newly added. I don't see how that question is relevant at this point yet?

Would you be happier if we forked your upstream source to provide our own, or provided a similar Python package with an identical API that we can use as a drop-in replacement?

This was already answered. Please don't repack my source in this repository was my request. I don't see how your suggestion is changing that.

Are you aware of similar efforts to package Home Assistant in a manner suitable for other Linux distros, such as Gentoo, that also include your packages (by necessity)? Do you have similar concerns there?

Yes, Gentoo isn't one of them at this point. I just did notice Fedora redistributing some of my packages because of your question, so will file a similar request with them.

[jtojnar]

Would you be happier if we forked your upstream source to provide our own, or provided a similar Python package with an identical API that we can use as a drop-in replacement?

This was already answered. Please don't repack my source in this repository was my request. I don't see how your suggestion is changing that.

The difference would be that users would no longer associate the software with you and they would surely go to nixpkgs to report bugs.

Another alternative would be 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?

---

We¹ can remove the package but that should only be a last resort after we have exhausted all other options.

That is because in the absence of the package in Nixpkgs, every NixOS user would have to create their own ambee package if they wanted to use it. And no, pip is not an option since it simply is not reproducible enough.

---

1. Well, there is not really any “we” – NixOS currently has no policy about this so the responsibility falls on the individual maintainers adding the package (@fabaff).

[frenck]

Would that be enough for you?

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

Would that be enough for you?

No. Please don't add it to this project. Thanks 👍

That is because in the absence of the package in Nixpkgs, every NixOS user would have to create their own ambee package if they wanted to use it. And no, pip is not an option since it simply is not reproducible enough.

I'm aware of the consequence. Luckily the Home Assistant project does not recommend or support that either (which is unrelated but makes me worry less).

[Mic92]

Result of nixpkgs-review pr 126326 run on x86_64-linux 1

2 packages built:

• python38Packages.ambee
• python39Packages.ambee

[Mic92]

No. Please don't add it to this project. Thanks +1

Request kindly denied due to the lack of technical reasons. If you don't wish your code to be packaged in nixpkgs, than make sure it is not a dependency of home-assistant or choose a different license (which should have the same result).

[frenck]

@Mic92 I will re-license and bump the dependency in a way that you guys can't distribute. Mainly because of not playing nice.

Thanks 👍

[Mic92]

@Mic92 I will re-license and bump the dependency in a way that you guys can't distribute. Mainly because of not playing nice.

Thanks +1

This would likely result in no longer being open source and hence the removal from home-assistant as well.

[frenck]

This would likely result in no longer being open source and hence the removal from home-assistant as well.

Unfortunately, you are wrong there. I will explicitly and publicly list parties that are allowed distribution in the license and allow for requesting distribution requests.

[frenck]

This pisses me off in a way and is disrespectful. I asked nicely.

[frenck]

PS: This package is outdated and not even compatible with the target release anymore.

But I guess that didn't matter, as long as you could merge, right?

[jtojnar]

Quoting from Debian’s thread on Distributing software written by hostile upstream developers:

If we can't have a sensible relationship with the upstream developers, then I believe it would be better not to expose Debian and our users to the problems that will likely arise from packaging and distributing their software.

I fully agree with that so I would be in favour of removing it.

[Mic92]

This is not really an issue for us, we can switch the license to an unfree one and than it is no longer build in nixpkgs but we only ship the build description for building it.

[frenck]

This is not really an issue for us, we can switch the license to an unfree one and than it is no longer build in nixpkgs but we only ship the build description for building it.

Please do from the start, that possibility wasn't provided.

[lukegb]

Locked for now. Please see #126677 (comment).

[dotlambda]

This package is outdated and not even compatible with the target release anymore.

Our update automation for Home Assistant prints a list of outdated dependencies, so this package will surely be updated in Nixpkgs when Home Assistant is.

[domenkozar]

@frenck I'd like to point out that core contributors from the Nix community are handling your request to support our project.

I'd like to clarify from your sponsors page the following statement:

Are you enjoying my work? And want to support me in my effort helping the world to become a better place by dedicating my time & knowledge to create & innovate open source software solutions. Allowing everybody on this earth the privilege to enjoy those things for free?

Do you still believe in that?

[sternenseemann]

There is no point in locking this thread if NixOS contributors are just gonna ignore that and continue posting here without @frenck being able to respond.

[eganist]

FYI, this thread has resulted in some pretty spirited discussion on hackernews with somewhat polarized perspectives in both directions.

[SuperSandro2000]

FYI, this thread has resulted in some pretty spirited discussion on hackernews.

We are aware of this. Thanks for the link anyway. :)

[frenck]

See: #126319 (comment)

[Eisfunke]

This would likely result in no longer being open source and hence the removal from home-assistant as well.

Unfortunately, you are wrong there. I will explicitly and publicly list parties that are allowed distribution in the license and allow for requesting distribution requests.

I feel the need to clarify that even a restriction like that would contradict the first criteria of the Open Source Definition:

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.

It would also contradict the Free Software Definition. A restriction like that would therefore result in the project no longer being open-source or free software.

[frenck]

I'm well aware of licensing and open source. It is my full-time daily driver and is visible in the very first request I made indicating the license permits it.

For me, this was not about licensing specifically. However, that point unfortunately is missed and got lost. Which is unfortunate. A lot blew up on the route, which just sucks for both parties.

In the end, I think the way this project distributes Home Assistant (and its integrations, including Ambee) is not providing the intended working and thus may surprise the end user. In the end, those users are likely to knock on the doors of the Home Assistant project and their integration maintainers, not this project. As a matter of fact, most of my packages in this project are outdated and don't match the distributed version of Home Assistant.

That is my concern, hence, my initially, friendly request to not include my packages, just like they don't include hundreds of other dependencies of Home Assistant either.

The way it is now discussed and thorn out of proportion is neither my nor (I'm sure) this project intention.

Open source is awesome, but there is more than just licensing. We have to be able to work together as well; or nothing gets built.

../Frenck

PS: I think the topic is handled and closed here: #126319 (comment)

[mweinelt]

I feel I've arrived somewhat late to the discussion, but I think it would be reasonable to weigh in here, because I'm home-assistant's (and coincidentally wled's) primary maintainer on nixpkgs these days.

The community consensus seems to be that we really want to keep these packages around, as dropping some of them will unnecessarily break user experiences, which I hope is also not in your interest. I'll also hope we can get to a cordial outcome despite our differences of opinion.

It is true that a lot of components to this day remain unsupported due to missing packages. This is due to the immense number of dependencies home-assistant relies on - but we are certainly catching up.

We also run a significant number of tests for the components where we have all dependencies packaged up. We invest a reasonable amount of time to debug failing tests and make sure things work within our environment.

We have rarely asked upstream for support, knowing full well that NixOS is a special snowflake with regard to how everything gets composed. But please recognize that this is the place where we collaborate to bring home-assistant together with our philosophy on how system administration should work.

We take great care when updating home-assistant and its leaf packages, and the index you found is created by tooling that also compares versions of packaged and expected dependencies, so it is somewhat unlikely that we'll ship home-assistant with an outdated dependency.

I also firmly believe that our community is well aware of how we compose home-assistant, so that it runs on NixOS, that they also will be highly aware when breaking changes occur, that they might be our fault.

I'd be happy to more clearly make our users aware, that our distribution is not supported upstream and that issues should first and foremost be directed to us, if that unburdens your project. It was certainly not our intention to sour the relationship with our upstreams.

I hope that puts all technical misunderstandings to rest and we can move on.

Martin Weinelt