| 2 Sep 2021 |
 b12f | Anyone know where this might be coming from? We've tried going back and forth between different branches, deleting lockfiles, etc. | 15:49:11 |
| b12f | This doesn't work
bud.inputs.beautysh.inputs.poetry2nix.inputs.flake-utils.follows = "digga/flake-utils-plus/flake-utils";
But I guess something like this would be the way to fix this, no? Interestingly, our flake.nix inputs are basically the same as for devos master
| 15:58:27 |
 @timdeh:matrix.org | It should work in theory at least | 15:59:37 |
| b12f | results in the following:
error: cannot find flake 'flake:beautysh' in the flake registries)
| 16:00:18 |
 ultranix | what do i do about error: input 'bud/beautysh/poetry2nix/flake-utils' follows a non-existent input 'beautysh/flake-utils' while trying to update flakes | 22:38:45 |
 David Arnold (blaggacao) | nix develop github.com:divnix/digga --command nix flake update | 22:41:55 |
| David Arnold (blaggacao) | may that could work... | 22:42:02 |
| David Arnold (blaggacao) | the problem is the local unpatched nix version... | 22:42:19 |
| ultranix | yeah i figured | 22:43:10 |
| David Arnold (blaggacao) | since that patch was merged, pain will be temporary. | 22:43:47 |
| b12f | I think for us what did it was running `nix flake lock --update-input <name>` at least the build has now been running for a while | 22:55:40 |
| b12f | `<name>` with the name of an input, one after the other down the list | 22:56:44 |
 tomberek | This came up in another channel as well. The UI for “nix flake update NAME” means that the NAME flake’s inputs are fetched. And this ends up being a registry lookup. And the most common failure case is “nixpkgs”. Because it resolves and looks as if it updated. But not your input in the current directory, but nixpkgs in your registry. | 23:13:22 |
| David Arnold (blaggacao) | From the error, I think the issue is https://github.com/NixOS/nix/pull/4641 (recently merged) | 23:14:47 |
| David Arnold (blaggacao) | https://github.com/NixOS/nixpkgs/pull/136463 should us all relief soon: https://github.com/NixOS/nixpkgs/pull/136463 | 23:15:46 |
| David Arnold (blaggacao) | speaking of nixfixes... does anybody know what it takes to solve: https://github.com/NixOS/nix/blob/af94b54db3a2be100731a215cb5e95f306471731/src/libexpr/flake/flake.cc#L306 | 23:24:23 |
| David Arnold (blaggacao) | * speaking of nixfixes... does anybody know what it takes to solve this fixme: https://github.com/NixOS/nix/blob/af94b54db3a2be100731a215cb5e95f306471731/src/libexpr/flake/flake.cc#L306 | 23:24:32 |
| 3 Sep 2021 |
 @gytis-ivaskevicius:matrix.org | Damn, i posted this screenshot and now somebody bought the domain 👀 | 07:46:09 |
| @gytis-ivaskevicius:matrix.org | 
Download image.png | 07:46:10 |
| @gytis-ivaskevicius:matrix.org | I wonder who spent such big bucks on it, its records are protected by namecheap | 07:46:42 |
| @gytis-ivaskevicius:matrix.org | Tho i find it difficult to imagine somebody buying it aside nix foundation due to the price | 07:47:07 |
| @timdeh:matrix.org | In reply to @blaggacao:matrix.org
speaking of nixfixes... does anybody know what it takes to solve this fixme: https://github.com/NixOS/nix/blob/af94b54db3a2be100731a215cb5e95f306471731/src/libexpr/flake/flake.cc#L306 I dunno, I've asked about this a number of times so I guess not 😅
I tried to find a code example of config being uploaded to the daemon elsewhere in the cli, but I didn't find anything like that (that I could make out at least) | 14:46:28 |
| @gytis-ivaskevicius:matrix.org | you guys may like this: | 20:33:14 |
| @gytis-ivaskevicius:matrix.org | 
Download image.png | 20:33:17 |
| @gytis-ivaskevicius:matrix.org | (To be fair that script was written ages ago way back on arch and not converted to Nix well) | 20:33:42 |
| 4 Sep 2021 |
| David Arnold (blaggacao) | Opinions?
# magic module that bundles all (re-)exported modules
# TODO: avoid these kind of downstream magic since it forgoes
# the indexing/inventory function of being explicit
nixosModule.imports = builtins.attrValues self.nixosModules;
Might that even be so useful that we should make it automatic with digga?
| 15:08:25 |
| David Arnold (blaggacao) | * Opinions?
{
# magic module that bundles all (re-)exported modules
# TODO: avoid these kind of downstream magic since it forgoes
# the indexing/inventory function of being explicit
nixosModule.imports = builtins.attrValues self.nixosModules;
}
Might that even be so useful that we should make it automatic with digga?
| 15:09:02 |
| David Arnold (blaggacao) | * Opinions?
{
# magic module that bundles all (re-)exported modules
# TODO: avoid these kind of downstream magic since it forgoes
# the indexing/inventory function of being explicit
nixosModule.imports = builtins.attrValues self.nixosModules;
}
Contrary to the todo, might that even be so useful that we should make it automatic with digga?
| 15:09:42 |
| David Arnold (blaggacao) | ( credits kreisys for this idea - I guess ) | 15:11:28 |
| David Arnold (blaggacao) | Also: semantically I noticed a shortcoming of the current naming of external*. digga can have an excellent second life as a flake management utility not specifically tied to manage nixos systems. Similar to flake-utils-plus, it exposes all the required primitives very elegantly. However, when users want to build their own libraries on top of digga, then external* -> nonExported* might be the better semantic. If you make a consolidating intermediate repo that pins down a comprehensive set of upstream modules, then you run into a situation where you explicitly want to re-export inputsed modules. | 15:26:28 |
