@waweic@chaos.social @schratze Yeah but a low barrier to entry is still *a* barrier to entry, and there are lots of reasons why it might not be practical to get something in there. Maybe there are licensing issues, maybe it's internal software, maybe you and the people managing that repo don't get along, maybe it's something of your own that *you* want to package but not suggest to anybody else that it is ready for use yet, etc.

Nix/Guix solve this on a much more fundamental level, by pretty much removing the concept of a "repository" as some specially-privileged thing, and instead just defining your system as a collection of configuration, some of which happens to describe how to build packages.

It doesn't care whether that 'build configuration' comes from the nixpkgs maintainers (in the case of Nix), or some internal repo, or is even defined inline in your system configuration - it's all just code that evaluates to a pile of packages, and with transparent opportunistic binary substitution.

In other words: nixpkgs, which is conceptually more or less equivalent to an "official" repository for Nix, uses the *exact same tools* that you use in constructing your system configuration, there is no privileged anything involved.

And you don't need to "build your packages against dependencies in nixpkgs" either (treating nixpkgs as strictly authorative and even third-party things have to de facto play by its rules); because of how the evaluation works, dependencies are just references to other packages, and version conflicts don't exist, so you can totally use dependencies from wherever.

So in other words: instead of having a model where there's one authorative source controlling the system and you just have to hope it leaves room for your requirements, you get an "authority-agnostic" system where you don't need *anybody's* permission to package something with the same degree of integration and reliability as in nixpkgs.