Fallback on builtin fetchers whenever possible

[nmattia]

#45 (comment)

@nlewo what do we gain from using the builtins as much as possible? Allowing use-cases where no nixpkgs can be found?

[nlewo]

Some projects use Nix only to generate files (json, yaml...). In theory, they don't need nixpkgs. So, it would be nice to allow such kind of project to use Niv without relying on nixpkgs.
Actually, I was thinking of kubenix, but it already uses nixpkgs! So, I'm not sure this is relevant.

[michaelpj]

Here's another use case: we have a repository X for org-specific nix stuff, which includes a default nixpkgs pin for people to use.

So I want to get my nixpkgs from there, which means that when I fetch X I need to do it with a builtin fetcher unless I want to fallback on the ambient nixpkgs (which I definitely do not want, in fact I'd like a way to turn it off).

[michaelpj]

Couple of approaches I can think of:

• Add extra types for the builtin versions of fetchers tarball-builtin, fetchurl-builtin etc.
• Add a builtin attribute that controls whether we try and use the builtin version of something. Most of the commonly used fetchers have builtin versions, so this would usually make sense.

[nlewo]

Fetchers such as dockerTools.pullImage, fetchFromGithub, fetchFromGitlab don't have a builtin version. So, if we decide to add them, I think dedicated fetchers (tarball-builtin, fetchurl-builtin) would be more suitable.
More concretely, I have open a PR to add a Docker fetcher (wip). Some users would like to be able to fetch git submodules (nixpkgs.fetchgit). I don't think the builtin version support this feature.

[michaelpj]

Yeah, that's the reason I went with dedicated names in #61.

[nmattia]

After long discussions we're now using the nixpkgs fetchers for all packages expect nixpkgs, at least when it comes to fetching tarballs and the like (i.e. not for git repos, where we use builtins.fetchGit to allow fetching private repos).