Nix Flakes | 875 Members | |
| 175 Servers |
| Sender | Message | Time |
|---|---|---|
| 3 Aug 2021 | ||
| Ivan Malison: | 04:38:18 | |
*
I want to know that to in order to reason about ownership of a certain file (by a flake) | 04:40:32 | |
*
I want to know that too in order to reason about ownership of a certain file (by a flake) | 04:40:46 | |
*
I want to know that too in order to reason about ownership of a certain file (by a flake, or even better by a particular commit) | 04:40:59 | |
In reply to @Las:matrix.orgRight. 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 | |
| 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 | |
| The way things work with flakes is certainly better, but full purity does have some downsides. | 04:46:14 | |
In reply to @elonsroadster:matrix.orgAs in your solution: It just makes the input an invariant. This is pretty cool! | 04:47:06 | |
In reply to @elonsroadster:matrix.org* As in your solution: It just makes that particular input an invariant. This is pretty cool! | 04:47:45 | |
| Often times I'm surprise by the marvles that ly behind this paradigm shift 😀 | 04:48:45 | |
| * Often times I'm surprise by the marvels that lie behind this paradigm shift 😀 | 04:49:00 | |
| 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 | |
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 | |
| 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 | |
btw, I did the same for bud: https://github.com/divnix/bud/blob/ed67004ac9929bb418f5eedacc50901f6787dba0/module.nix#L90-L94 | 04:56:26 | |
| 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 | |
| What you're asking to do is specifically what Nix sets out to avoid. | 07:52:03 | |
In reply to @elonsroadster:matrix.orgThe switch-to-configuration script is hardly a "system update" | 07:55:32 | |
| 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 | |
Specifically, I do nix build conf#play | 07:57:01 | |
| 12:24:52 | ||
| 14:02:45 | ||
| 4 Aug 2021 | ||
| Redacted or Malformed Event | 20:11:49 | |
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 | |
Is there a way to create a gcroot for this devShell? | 20:12:53 | |
Should nix build .#devShell.x86_64-linux work? | 20:13:39 | |
| * 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 | |
| It fails with the following: | 20:30:07 | |
| 20:30:14 | |
| 23:08:58 | ||