| 30 Dec 2021 |
|  Adit joined the room. | 07:44:28 |
|  ereslibre joined the room. | 10:22:12 |
 flyx | I'm writing another article about Nix Flakes, and I'd like to write it in a way that enables me to automatically test whether the Nix code I show actually works. is there per chance someone else who did that and has a repo for it available where I can draw inspiration from? | 19:13:22 |
| flyx | In reply to @ilkecan:matrix.org
You need to use nix-filter or something equivalent. when using nix-filter on root = self; it complains that root isn't a path. using self.outPath or builtins.toPath self doesn't work either. | 20:50:34 |
 ilkecan | In reply to @flyx:flyx.org
when using nix-filter on root = self; it complains that root isn't a path. using self.outPath or builtins.toPath self doesn't work either. You can use ./. | 20:52:39 |
| flyx | hmm, why do we have self then? | 20:53:37 |
| ilkecan | In reply to @flyx:flyx.org
hmm, why do we have self then? self is an attribute set that has multiple attributes, one of them being outPath. In my experience, self is generally used to refer to the outputs of the current flake (e.g. self.packages). As for why self has an outPath attribute when we have ./.; I am not sure whether self.outPath is required or better than ./. for some cases but removing a possible edge case (all flake inputs except self has outPath) is enough of a reason for me.
nix-filter expects root to be a Nix path but self.outPath is a string with context. While I don't know why that is necessary, one reason might be there was a bug in Nix that prevented filtering strings with context. But that should be possible now so the assertion in nix-filter might not be needed anymore.
| 21:59:12 |
| ilkecan | In reply to @flyx:flyx.org
hmm, why do we have self then? * self is an attribute set that has multiple attributes, one of them being outPath. In my experience, self is generally used to refer to the outputs of the current flake (e.g. self.packages). As for why self has an outPath attribute when we have ./.; I am not sure whether self.outPath is required or better than ./. for some cases but removing a possible edge case (all flake inputs except self has outPath) is enough of a reason for me.
nix-filter expects root to be a Nix path but self.outPath is a string with context. While I am not sure why that assertion is necessary, one reason might be there was a bug in Nix that prevented filtering strings with context. But that should be possible now so the assertion in nix-filter might not be needed anymore.
| 22:00:04 |
 tomberek | using self is generally preferred over ./. | 22:01:17 |
| tomberek | and at first it was unknown exactly what parts of storePath, path, filterSource, etc were safe, so we started with most of them not being allowed, and are slowly re-allowing them as we learn what can be done while retaining purity. | 22:02:19 |
| ilkecan | In reply to @tomberek:matrix.org
using self is generally preferred over ./. Why is that? | 22:03:16 |
| ilkecan | Is it because of style or is there a difference between the two? | 22:04:37 |
| tomberek | i think it is more resilient when it comes to things like the name of the folder it happens to be in | 22:07:15 |
| ilkecan | Unless If I misunderstood you I don't think that is the case because both will refer to the same Nix store path in the form of /nix/store/<hash>-source. Since flake evaluation happens in the Nix store, possible impurity from the name of the root directory is avoided altogether. | 22:13:31 |
| ilkecan | In reply to @ilkecan:matrix.org
self is an attribute set that has multiple attributes, one of them being outPath. In my experience, self is generally used to refer to the outputs of the current flake (e.g. self.packages). As for why self has an outPath attribute when we have ./.; I am not sure whether self.outPath is required or better than ./. for some cases but removing a possible edge case (all flake inputs except self has outPath) is enough of a reason for me.
nix-filter expects root to be a Nix path but self.outPath is a string with context. While I am not sure why that assertion is necessary, one reason might be there was a bug in Nix that prevented filtering strings with context. But that should be possible now so the assertion in nix-filter might not be needed anymore.
I think lib.pathIsDirectory can be used instead of builtins.isPath in that assertion. | 22:41:48 |
| 31 Dec 2021 |
 brendanzab | is there a way to check the flake schema somehow? I was running nix flake check, assuming it was checking the schema, but if seems like it let through a bug with how I'd defined my apps: https://github.com/brendanzab/ocaml-flake-example/pull/5/files | 08:48:04 |
| brendanzab | it only popped up when I ran nix flake show and got:
git+file:///.../ocaml-flake-example?ref=main&rev=840f7782276b4e1cc17c3baa3fae03247d188c78
├───apps
│ ├───aarch64-darwin
error: not an app definition
| 08:48:56 |
| brendanzab | is seems like that produced an non-zero exit code though. should I be running nix flake show in CI? | 08:50:00 |
|  Hrafn Blóðbók left the room. | 11:18:49 |
| ilkecan | In reply to @brendanzab:matrix.org
is there a way to check the flake schema somehow? I was running nix flake check, assuming it was checking the schema, but if seems like it let through a bug with how I'd defined my apps: https://github.com/brendanzab/ocaml-flake-example/pull/5/files That sounds like a bug. nix flake check should also check that apps.<system>.<name> is an app definition. | 13:25:31 |
 balsoft | In reply to @ilkecan:matrix.org
Unless If I misunderstood you I don't think that is the case because both will refer to the same Nix store path in the form of /nix/store/<hash>-source. Since flake evaluation happens in the Nix store, possible impurity from the name of the root directory is avoided altogether. It is different for flake-compat IIRC | 13:26:55 |
| balsoft | In reply to @brendanzab:matrix.org
is there a way to check the flake schema somehow? I was running nix flake check, assuming it was checking the schema, but if seems like it let through a bug with how I'd defined my apps: https://github.com/brendanzab/ocaml-flake-example/pull/5/files Sounds like a bug in nix flake check indeed | 13:31:32 |
| brendanzab | gotcha. glad I wasn't missing anything 😅 | 13:35:17 |
| balsoft | In reply to @brendanzab:matrix.org
is there a way to check the flake schema somehow? I was running nix flake check, assuming it was checking the schema, but if seems like it let through a bug with how I'd defined my apps: https://github.com/brendanzab/ocaml-flake-example/pull/5/files Also, sorry for self-promotion, but you may be interested in https://github.com/tweag/opam-nix | 13:50:01 |
| brendanzab | oh interesting, thanks! will have a look | 13:52:43 |
| brendanzab | I was mainly trying to use dune for this stuff, so not sure if it will help? but I might be missing something. still looks useful, could it help for pulling down OPAM dependencies without needing them to be added to nixpkgs? | 13:55:32 |
| balsoft | In reply to @brendanzab:matrix.org
I was mainly trying to use dune for this stuff, so not sure if it will help? but I might be missing something. still looks useful, could it help for pulling down OPAM dependencies without needing them to be added to nixpkgs? Yep, that's exactly what it's for | 13:58:24 |
| balsoft | You give it a .opam file and it turns it into a nix derivation for you | 13:58:42 |
| balsoft | It can use dune for actually building the package. | 13:59:04 |
| brendanzab | ahh - I think in my current thingo I was using (generate_opam_files true), but perhaps that's a bad thing to be relying on? | 14:00:37 |
