Is there any reason why builtins.fetchTarball is used more often than pkgs.fetchFromGitHub for e.g. pinning packages?

Help
1

Hello,
I’m new here. While configuring my dotfiles, among other things, I’ve noticed, that almost every package uses builtins.fetchTarball for pinning (like NUR or as described in the nixos wiki: Pinning).

As most of these packages are hosted on GitHub, is there any reason why not to use pkgs.fetchFromGitHub in the configuration.nix?
As far as I’ve read pkgs.fetchFromGitHub should be used for all GitHub packages
Are there any compatibility issues with this (e.g. with a fresh installation)?

1 Like
2

If you use pkgs.X, you are depending on having some nixpkgs around for bootstrapping. If you use builtins.fetchTarball, you only depend on nix.

2 Likes
3

Thanks, that’s what I’ve guessed.

But is there any (practical) drawback by depending on existing nixpkgs for bootstrapping?
With the assumption, that I’m installing a new NixOS installation with my dotfiles, where nixpkgs are pinned with pkgs.fetchFromGitHub.
By default the channel provided by the NixOS installation should provide nixpkgs doesn’t it?
So for the first installation, the configuration.nix uses the non-pinned pkgs.fetchFromGitHub until the pinned nixpkgs are fetched if I understand correctly.

So with my current understanding, this might only be dangerous, if the non-pinned nixpkgs have an incompatible change in pkgs.fetchFromGitHub?

Still I see the reason why builtins.fetchTarball is used with pinning nixpkgs.
But apart from nixpkgs, is there a drawback by using pkgs.fetchFromGitHub for other packages like NUR?

4

You actually can’t count on a system having a <nixpkgs> to bootstrap with. Nix doesn’t guarantee the user has this channel or anything like it in NIX_PATH. Plus, if fetchFromGitHub is bugged or something on the user’s nixpkgs version, your expression won’t work.

Other than being built into nix vs requiring nixpkgs, the other big difference is that fetchTarball is eval-time, and fetchFromGitHub is build-time. Each of these has an advantage. Eval-time means you can import code from it without it being “import-from-derivation” (where you import a nix expression from the output of a derivation, which has considerable drawbacks). But build-time means it can happen in parallel with other builds, rather than blocking the evaluator, which is why it’s better to use one of the fetchers from pkgs as src in a derivation.

5 Likes