Deceptive Scope Mismatches

[blaggacao]

@danieldk

Of course, it is possible to separate fetchers (as builtins shows). But there is a good reason that there are fetchers in nixpkgs, it means that you can make more complex fetchers that use other derivations in nixpkgs plus that you can write them in Nix (as opposed to C++). You could separate them out of nixpkgs as well, but that would mean that you’d to maintain various derivations (e.g. unzip, fossil, darcs, compilers, stdenv itself, etc.) in two places. The only downside that I see is that you need all of nixpkgs to use these fetchers. But is anyone really using Nix without nixpkgs?

That is really interesting. So it already is content addressable. It also means that I can safely use pinned version of nixpkgs on fetchers while using another pinned nixpkgs version for the evaluation of packages and configuration. This allows for cleaner patterns in a well-structured repo, and I would explicitly not have to pass nixpkgs all around the place, rather only to the (alas single) entry point of my build evaluation.

In the context of the initial example from Silvan’s nix config I could safely write:

{
   fetchers = import <nixpkgs>; # or use a flake
}

Then the only thing that would really be nice would be to enable this form through some intra-nixpkgs monorepo factoring (without actually breaking it apart):

{
   fetchers = import <nixpkgs/pkgs/pkgs-lib/fetchers>; # or use a flake
}

It is an abstract benefit, but it would encourage to write more concise derivations (exhibiting the intricacies you explained about fixed output derivations) and at least give expressive means to avoid putting everything into the same global namespace (which might be a real problem of it’s own).