Let’s go one further and compel Apple, Microsoft, and Google to open source their entire operating systems. :)
Plutus, Haskell, Nix, Purescript, Swift/Kotlin. laser-focused on FP: formality, purity, and totality; repulsed by pragmatic, unsafe, “move fast and break things” approaches
AC24 1DE5 AE92 3B37 E584 02BA AAF9 795E 393B 4DA0
Let’s go one further and compel Apple, Microsoft, and Google to open source their entire operating systems. :)
Wow. I stand corrected. That’s actually scary. Has anyone mentioned a solution to this glaring issue? It’s fairly trivial to do that by the way. All that needs to happen is to hash the output of each plugin and the version numbers and compatibility issues would be easier to understand and reproducible.
I’m guessing that those plugins have their own nix derivations that are handled in a more reliable manner. No wonder the dude has extra technical debt popping up! He hasn’t even thought to atomically declare his dependencies.
This is so weird. There’s a lot of white knights in here shooting the messenger.
I’m not upset. I just think these kinds of anti-open source actions should be well-known by such a large, popular community centered around a project that could potentially have their source code closed and monetized at the drop of a hat.
It obviously is.
Frenck actually deserves it.
Yeah. He came to the nix people bitching because he didn’t understand their technology and chose to be mean rather than direct the questions to nixpkgs. He tried to obfuscate his code to punish nix people which goes directly against the open source license.
Maybe don’t come to them bitching if you don’t understand what you’re talking about?
You should probably write a version of that to Frenck and yourself too. I’m just here pointing out shitty anti-open source behavior. Not sure how they makes me culpable…. But go off qween.
That’s the thing that NONE of you get. We literally don’t need anything nor are we asking anything of Frenck. We packaged Home-Assistant and there it sits in nixpkgs without ANY involvement from Frenck.
You don’t get to dictate or create work for an open source project that wasn’t designed to play well in your environment.
It doesn’t matter how it was designed. The purpose of Nix is to get it to work in our world. We don’t request any changes to packages and pride ourselves on being able to build things without the involvement of the original team. I think I am going to repeat this point a few more times….
come up with a proposal that the upstream accepts and implement it.
that goes against Nix philosophy. They ask nothing of Frenck.
Better yet, come up with a design of your system that accommodates the upstream project.
That is literally what nix is. We pride ourselves on building any project without the involvement of nor asking anything of the original creator.
That last part is wrong. Nixpkgs asks NOTHING of the maintainers of the original packages. We pride ourselves on being able to RELIABLY build any software out there using only what is available to build the package normally. We just add steps to make that REPRODUCIBLE because we think that is important. If someone went to Frenck about the issues, they certainly weren’t directed there by nixpkgs people.
No one said he was. No one said that. They literally said, “direct any issues to the nixpkgs maintainer”.
Python generates hashed lock files of every dependency it builds. It simply queries that and matches that against its own builds. If they’re not using lock files and such, there are MUCH bigger problems in that project. ;)
That immutable state considers the lock files of ALL the dependencies listed and needed to build the software. You don’t seem to understand the technology enough to weigh in.
It downloads them then compares them with the expected hashes. If they don’t match, it literally won’t build.
I understood the point well. The author (and perhaps you) don’t seem to. The technical issues he outlined show a lack of understanding about how nix works with Pypi dependencies. Nix builds EVERYTHING and uses the hashes and lock files from the package. It builds the EXACT versions of PIP packages that the original package used. So any dependencies that the author created point to the hashes that nixpkgs expects. There should be zero difference between the two since they are hashed using inputs. In conclusion, Frenck was being a dick because he didn’t understand Nix and hashed atomic build systems.
If someone from nixpkgs goes to him about something breaking, it is literally because his code broke something. The only possible failure on the nixpkgs part would be not bumping the pkg version of a dependency quick enough…but this is a non-issue since home-assistant pkg builds all of those in its derivation FROM HA’s lock files.
@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 👍
What an asshole.
IMO, I think it would be wise for the community to fork and move away from his (utterly ubiquitous) project before it is too late. Lest we get another “OpenAI” or Raspberry Pi IPO.
It feels like magic. I think of it as the glue that makes almost all of my software work together seamlessly. I can’t wait to use it for one-click deployments of my software on a server or high-availability cluster.
This is why I decided to learn Nix. I built dev environment flakes that provision the devshell for any language I intend to use. I actually won’t even bother unless I can get something working reliably with Nix. ;)
For example, here’s a flake that I use for my Python dev environment to provide all needed wiring and setup for an interactive Python web scraper I built:
{
description = "Interactive Web Scraper";
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs?ref=nixpkgs-unstable";
utils.url = "github:numtide/flake-utils";
};
outputs = { self, nixpkgs, utils }: utils.lib.eachSystem ["x86_64-linux"] (system: let
pkgs = import nixpkgs { system = system; };
in rec {
packages = {
pyinputplus = pkgs.python3Packages.buildPythonPackage rec {
pname = "pyinputplus";
version = "0.2.12";
src = pkgs.fetchPypi {
inherit pname version;
sha256 = "sha256-YOUR_SHA256_HASH_HERE";
};
};
pythonEnv =
pkgs.python3.withPackages (ps: with ps; [ webdriver-manager openpyxl pandas requests beautifulsoup4 websocket-client selenium packages.pyinputplus ]);
};
devShell = pkgs.mkShell {
buildInputs = [
pkgs.chromium
pkgs.undetected-chromedriver
packages.pythonEnv
];
shellHook = ''
export PATH=${pkgs.chromium}/bin:${pkgs.undetected-chromedriver}/bin:$PATH
'';
};
});
}
There’s always Nix but the dev behind HA has a personal vendetta against Nix people building his software (for some ridiculously stupid reason). We packaged home assistant in nixpkgs anyway because we don’t negotiate with terrorists.
I’ve been thinking a lot about this. Another way might be for a Lemmy instance to run a stake pool from the same machine. They could offer perks to users while also not requiring donations directly. Perhaps even reward users with the pool’s native tokens for every post they submit or something (this is a great place to bring up the drawbacks and very real issues that offering a perverse incentive can have: Cobra Effect).
The mere use of the chain (in this case Cardano would be my recommendation honestly because I prefer the tech and not because I have a bag of it) because that stake pool could mint native tokens and use those as a currency for use on their instance. Native tokens on Cardano are cheaper and not subject to the same fees as other chains to use and mint. So it would allow that instance to have its own native currency with very little overhead.
Look at Kbin’s old code. There’s some mention of Cardano wallets on there so I’m guessing that the creator of that was interested in this idea.