| 20 Aug 2021 |
 Gytis Ivaskevicius | * This function fetches it but it is not a derivation which (atleast from my point of view) implies that it is internal builtin and should be avoided for normal usecases | 10:39:20 |
| Gytis Ivaskevicius | Do you get what I mean? | 10:39:30 |
| Gytis Ivaskevicius | * This function fetches it but it is not a derivation which (atleast from my point of view) implies that it is internal builtin and should be strongly avoided for normal usecases | 10:40:11 |
 sterni | that is the wrong thinking, I'd say. It has some properties and should consequently be used for the appropriate use cases | 11:58:40 |
| sterni | it shouldn't be used for fetching sources in most cases because it means that the sources will necessarily be fetched at compile time (since the store path needs to be created), here derivations are more appropriate because they can be instantiated and built later | 11:59:29 |
| sterni | if you need the fetch result at eval time, using builtin fetchers is much better | 11:59:43 |
| sterni | in a lot of cases this doesn't matter too much though, and in most cases where it matters its forbidden anyways (restricted eval limits it to certain urls, pure eval forbids it completely) | 12:01:01 |
| Gytis Ivaskevicius | I feel like one of us misunderstands something. You said "that is the wrong thinking" but then basically agreed with me 🤔 | 13:20:37 |
| Gytis Ivaskevicius | Anyways, what i do care about is why Nix is not able to do such things on its own, why cant Nix take care of git fetching or more importantly tarball fetch for our packages? 🤔 | 13:22:50 |
| Gytis Ivaskevicius | Has there been any conversation on this? (I would imagine so 🤔) | 13:23:09 |
| Gytis Ivaskevicius | Also i feel like trivial-builders.nix is somewhat similar. I feel like thats something that Nix itself should be able to do 🤔 | 13:24:09 |
 Las | In reply to @gytis-ivaskevicius:matrix.org
Anyways, what i do care about is why Nix is not able to do such things on its own, why cant Nix take care of git fetching or more importantly tarball fetch for our packages? 🤔 ? | 17:39:07 |
| Las | It already does this? | 17:39:09 |
| Gytis Ivaskevicius | Do you think it is a good practice to use builtins.fetchTarball for our derivation sources? | 17:40:42 |
| Gytis Ivaskevicius | (just making sure, gathering oppinions) | 17:40:55 |
 pamplemousse | Redacted or Malformed Event | 18:07:03 |
| pamplemousse | Redacted or Malformed Event | 18:08:28 |
| sterni | In reply to @gytis-ivaskevicius:matrix.org
Do you think it is a good practice to use builtins.fetchTarball for our derivation sources? using fetchTarball for our derivation sources would mean that (worst case) a hydra eval takes as long as fetching changed source tarball. using fixed output derivations pushes the fetching to the build time and is thus preferrable | 21:51:51 |
| Gytis Ivaskevicius | Yep, exactly | 21:53:13 |
| sterni | In reply to @gytis-ivaskevicius:matrix.org
I feel like one of us misunderstands something. You said "that is the wrong thinking" but then basically agreed with me 🤔 You were saying that it should be avoided for normal usecase - I disagree: fetching a repo used at eval time (something like naersk) is a normal use case | 21:53:49 |
| Gytis Ivaskevicius | Now back to the question - What is the reason of not having the one that could be used for derivations (aka the one that returns a derivation) | 21:54:17 |
| sterni | In reply to @gytis-ivaskevicius:matrix.org
Also i feel like trivial-builders.nix is somewhat similar. I feel like thats something that Nix itself should be able to do 🤔 in the end these are just wrappers around derivation and add nothing new and they mostly exist to make very simple derivation integrate well with our mkDerivation infrastructure | 21:54:51 |
| Gytis Ivaskevicius | In reply to @sternenseemann:systemli.org
You were saying that it should be avoided for normal usecase - I disagree: fetching a repo used at eval time (something like naersk) is a normal use case yeah, i kinda forgot about cases like that, have been on flakes for quite sometime | 21:54:56 |
| sterni | In reply to @gytis-ivaskevicius:matrix.org
Now back to the question - What is the reason of not having the one that could be used for derivations (aka the one that returns a derivation) I'd say simplicity and flexibility, but it has been proposed before to change this: https://github.com/NixOS/nix/issues/2270 | 21:55:32 |
| Gytis Ivaskevicius | In reply to @sternenseemann:systemli.org
in the end these are just wrappers around derivation and add nothing new and they mostly exist to make very simple derivation integrate well with our mkDerivation infrastructure I would expect bit of a speed up due to amount of it is being used | 21:56:01 |
| Gytis Ivaskevicius | (to be fair one could just create a custom binary for this) | 21:56:23 |
| Gytis Ivaskevicius | Also I am not sure about simplicity, its like "bit of code in nix" vs "loats of code in nixpkgs" | 21:57:18 |
| sterni | simplicity is not about code size and less code in nix is always good | 21:58:22 |
| sterni | it'd mostly be having another special thing in nix | 21:58:32 |
| sterni | whereas derivations and fixed-output derivations are quite simple concepts that can be used for all sorts of things | 21:58:56 |
