| 16 Aug 2021 |
|  tomberek joined the room. | 01:33:35 |
 ultranix | I didn't start using follows until devos, what's good about it? every flake follows one nixpkgs commit for example? and you wont need to download a separate one for every flake? | 01:52:07 |
 David Arnold (blaggacao) | Exactly, follows are a necessary consequence of coercing inputs. Remember that overlays is not a language level implementation, but a nixpkgs idiom. | 01:55:03 |
| ultranix | yes | 01:55:26 |
 @timdeh:matrix.org | I mean follows help keep the closure size under control, which is fine for the flake developer, but it can cause cache misses when used unexpectedly by the consumer | 02:04:31 |
| @timdeh:matrix.org | which is why I debate in my head whether nix even need such a notion (since it also complicates the design a bit) | 02:04:59 |
| @timdeh:matrix.org | In my mind, it might be better to simply cache "hot" flakes like nixpkgs locally and allow flakes to remain immutable. Follows can be seen as an unexpected contract breach, since changing the inputs changes everything about the hash, and I suspect that this may even start to cause bigger headaches when CA becomes a thing. | 02:09:59 |
| David Arnold (blaggacao) | Yeah, with heavy use of follows upstream caches get essentially useless. I think there is only a very nascent push to make the use of release channels more feasible at large (backporting bot). To mitigate the problems you describe, the community at large must also increasingly play by some sort of release heart beat. | 02:15:55 |
| tomberek | the option to override is powerful and hence dangerous, but there are clear example of wanting it | 02:16:16 |
| tomberek | i had thought that a flake without a flake.lock is very similar to a channel semantically | 02:17:06 |
| @timdeh:matrix.org | yeah, I go back and forth on it. Maybe, in the future, trustix caches will simply disallow them to ensure trust, but we can still keep them 🤷 | 02:17:20 |
| David Arnold (blaggacao) | Atomic pinning could also lead to combinatoric closure explosion, if not any sort of convention can sync upstream flakes effectively. | 02:19:20 |
| David Arnold (blaggacao) | ... I mean, once flakes get really pervasive. | 02:19:52 |
| @timdeh:matrix.org | yeah, the follows thing, as tomberek kinda mentioned, could be seen as the same sort of impurity that channels caused, but in an even sneakier fashion 😅 | 02:21:36 |
| tomberek | is the fact that there is a "follows" somewhere in the chain of flakes somehow visible? is that fact tracked in a ".lock" or something? | 02:22:41 |
| @timdeh:matrix.org | If done by the developer then yes, it would be tracked in the upstream lock file. As a user, you can generate your own lock file if you have the repo locally. You can also override stuff on demand with the cli | 02:23:53 |
| @timdeh:matrix.org | I just don't like that it changed the upstream flake developers intentions from out under them. When flakes get more pervasive, as David Arnold (blaggacao) points out, I could imagine a lot of github issues opened by naive users not realizing that changing the inputs is the underlying cause of whatever problem they experience | 02:25:07 |
| David Arnold (blaggacao) | In reply to @tomberek:matrix.org
is the fact that there is a "follows" somewhere in the chain of flakes somehow visible? is that fact tracked in a ".lock" or something? not explicitly. | 02:26:06 |
| @timdeh:matrix.org | I mean it's visible in the flake.nix | 02:26:30 |
| tomberek | (okay, just tested it) it's tracked in the flake.lock as well. Well, so the question is: "is the tool useful enough to warrant possible misuse?" | 02:27:37 |
| tomberek | or, "what can we do to mitigate misue?" | 02:28:06 |
| David Arnold (blaggacao) | In reply to @tomberek:matrix.org
(okay, just tested it) it's tracked in the flake.lock as well. Well, so the question is: "is the tool useful enough to warrant possible misuse?" you mean by the [ ] path syntax? | 02:28:42 |
| @timdeh:matrix.org | Maybe some kinda of warning when a user is writing their own flakes, and overrides the inputs of one of their flake dependencies? Something like:
warning, changing inputs can potentially cause rebuilds, and or invalidate trusted packages | 02:31:05 |
| tomberek | The docs have a blurb about "generally not useful". Perhaps add a more direct explanation of the risks? | 02:37:46 |
 @gytis-ivaskevicius:matrix.org | David Arnold (blaggacao): Good luck on your first day at work ;) | 03:41:40 |
| @gytis-ivaskevicius:matrix.org | (They grow up so fast <3) | 03:41:48 |
| @timdeh:matrix.org | 😆 | 11:49:46 |
|  @vherrmann:shmerver.de joined the room. | 19:43:44 |
| @vherrmann:shmerver.de | wink wink | 19:45:10 |
| @vherrmann:shmerver.de | What relevance has the inherit inputs statement in the devos template? | 19:45:50 |
