| 3 Aug 2021 |
 elonsroadster | In reply to @Las:matrix.org
I don't think he wants to copy the files to the store. I think he wants to refer to the files by their actual path, so that the system refers to paths outside the Right. The reason for this is that is rather not worry about the scripts in my dotfiles being out of sync with what I have put in my nix store. I realize that this is sort of a dumb concern, and that any new dependencies that these scripts have would still need associated system updates, but it just feels a bit heavy weight to need to do a system update every time I tweak or add a new user script. | 04:42:23 |
| elonsroadster | Anyway, the solution I settled on is adding a module that takes a parameter that is the absolute path to my dotfiles repo that is defaulted to /home/my-user/dotfiles which is where I almost always put them. If I out them somewhere else this parameter will need to be specified. Reminds me a bit of how the system parameter now needs to be specified in flakes. | 04:45:07 |
| elonsroadster | The way things work with flakes is certainly better, but full purity does have some downsides. | 04:46:14 |
 David Arnold (blaggacao) | In reply to @elonsroadster:matrix.org
The way things work with flakes is certainly better, but full purity does have some downsides. As in your solution: It just makes the input an invariant. This is pretty cool! | 04:47:06 |
| David Arnold (blaggacao) | In reply to @elonsroadster:matrix.org
The way things work with flakes is certainly better, but full purity does have some downsides. * As in your solution: It just makes that particular input an invariant. This is pretty cool! | 04:47:45 |
| David Arnold (blaggacao) | Often times I'm surprise by the marvles that ly behind this paradigm shift 😀 | 04:48:45 |
| David Arnold (blaggacao) | * Often times I'm surprise by the marvels that lie behind this paradigm shift 😀 | 04:49:00 |
| elonsroadster | I guess the point is that any parameter that could be passed in to a flake needs to be defined within the flake file. Flakes outputs must basically be enumerable. | 04:50:42 |
| David Arnold (blaggacao) | But I still want to reason about the ownership of files owned by a particular flake. like in self.ownershipId == path.ownershipId | 04:51:40 |
| elonsroadster | It just feels to me like maybe complete purity is a bit limiting here. I get that it buys you a lot, but I do wonder if some sort of compromise that gets the best of both worlds is possible. | 04:51:51 |
| David Arnold (blaggacao) | btw, I did the same for bud: https://github.com/divnix/bud/blob/ed67004ac9929bb418f5eedacc50901f6787dba0/module.nix#L90-L94 | 04:56:26 |
 colemickens 🏳️🌈 | I don't know how a projects disk location could possibly be a good thing to specifically provide to what is supposed to be a reproducible hermetic environment. | 07:51:47 |
| colemickens 🏳️🌈 | What you're asking to do is specifically what Nix sets out to avoid. | 07:52:03 |
 Las | In reply to @elonsroadster:matrix.org
Right. The reason for this is that is rather not worry about the scripts in my dotfiles being out of sync with what I have put in my nix store. I realize that this is sort of a dumb concern, and that any new dependencies that these scripts have would still need associated system updates, but it just feels a bit heavy weight to need to do a system update every time I tweak or add a new user script. The switch-to-configuration script is hardly a "system update" | 07:55:32 |
| Las | Even if you have an extremely complex system configuration on an underpowered machine, evaluation + switching should not take more than a minute. What I do to test e.g. mpv with a new configuration is that I have a wrapper for it that adds the necessary config files, then I rebuild just that if I want to test just that. | 07:56:42 |
| Las | Specifically, I do nix build conf#play | 07:57:01 |
|  Florian | W3F - OoO joined the room. | 12:24:52 |
|  nf joined the room. | 14:02:45 |
| 4 Aug 2021 |
 Jez (he/him) | Redacted or Malformed Event | 20:11:49 |
| Jez (he/him) | I have a flake.nix with devShell as it's only output, and the derivation keeps getting rebuilt for no reason, presumably because it gets garbage collected | 20:12:32 |
| Jez (he/him) | Is there a way to create a gcroot for this devShell? | 20:12:53 |
| Jez (he/him) | Should nix build .#devShell.x86_64-linux work? | 20:13:39 |
| Jez (he/him) | * I have a `flake.nix` with `devShell` as its only output, and the derivation keeps getting rebuilt for no reason, presumably because it gets garbage collected | 20:24:26 |
| Jez (he/him) | It fails with the following: | 20:30:07 |
| Jez (he/him) | ❯ nix build .#devShell.x86_64-linux
error: builder for '/nix/store/4z64v9y8a6ic2ppgixg2z0d0zqnghvb5-nix-shell.drv' failed with exit code 1;
last 4 log lines:
> nobuildPhase
>
> This derivation is not meant to be built, aborting
>
For full logs, run 'nix log /nix/store/4z64v9y8a6ic2ppgixg2z0d0zqnghvb5-nix-shell.drv'.
| 20:30:14 |
|  jul1u5 joined the room. | 23:08:58 |
 tomberek | Jez (he/him): can you publish your flake repo somewhere? | 23:26:43 |
| 5 Aug 2021 |
| colemickens 🏳️🌈 | Jez (he/him): stick an ".inputDerivation" there on the end of that ;) | 04:51:38 |
 j-k | Is there a nice way to build aws AMIs using flakes?
I've been reading this https://github.com/nh2/nixos-ami-building but I'm not sure how to cleanly do it with flakes | 11:05:14 |
| j-k | ami = import "${nixpkgs}/nixos/release.nix" {
configuration = ./my/file/configuration.nix;
};
λ nix build .#ami.amazonImage.x86_64-linux
λ ls ./result
nix-support nixos-amazon-image-21.11pre130979.gfedcba-x86_64-linux.vhd
is promising
| 11:16:44 |
