| 24 Oct 2023 |
K900 | In reply to@pcloud:matrix.org Sure, but I don't think we're using nixpkgs poetry in poetry2nix We should still be using nixpkgs overrides? | 13:12:33 |
K900 | Though maybe not | 13:12:38 |
cpcloud | There's a vendored version of poetry in poetry2nix | 13:12:50 |
cpcloud | partially vendored | 13:13:02 |
cpcloud | the source isn't there, but there's a src.json that seeds a derviation that builds it | 13:13:25 |
cpcloud | * the source isn't there, but there's a src.json that seeds a derviation that builds it from the github release | 13:13:30 |
K900 | I wonder if we should just get rid of that | 13:13:32 |
K900 | We should be able to use the same bootstrap chain as nixpkgs now | 13:13:47 |
cpcloud | "should" :) | 13:13:57 |
cpcloud | Lemme give it a shot | 13:14:46 |
K900 | https://github.com/NixOS/nixpkgs/pull/263139 | 13:19:59 |
K900 | Pushed up the fix to nixpkgs | 13:20:03 |
cpcloud | Nice, thanks | 13:20:23 |
cpcloud | Alright, I'm moving poetry over to the one from nixpkgs | 13:33:28 |
cpcloud | Is there a way to overlay your changes onto the nixpkgs coming from the poetry2nix flake.nix? I suppose one option is to do that on my nixpkgs fork | 13:39:01 |
cpcloud | Sweet, that patch addresses the issue | 13:45:45 |
virtu | Is there a set of best practices when creating applications/services with poetry2nix? My first non-informed approach would have been to include a package.nix and a module.nix in the root of the repo, and include them in flake.nix. But then I came across NUR (Nix User Repositories), which appears to be a dedicated spaces for defining modules and packages separate from the code. Is this considered the standard way? | 13:56:42 |
K900 | Not really, no | 13:58:18 |
K900 | NUR predates flakes | 13:58:22 |
K900 | And is mostly designed as a big aggregate of community repos | 13:58:30 |
virtu | Okay, thanks. Any conventions about where to put package and module definitions? Is it okay to have a flake.nix that uses module.nix and package.nix, or do I put everything into the flake? If you happen to know a project that uses the approach I could use as a reference, that'd be great. | 14:02:00 |
K900 | There's no official rules | 14:02:13 |
K900 | Just organize stuff in a way that fits your workflow | 14:02:20 |
virtu | I thought as much, but if there's like some community consensus or best practice, I'd like to follow that. But if there isn't, I'll just give it a shot and put everything into the flake to avoid cluttering the repo (and avoid confusing non-nix people) | 14:03:23 |
K900 | There really isn't | 14:04:25 |
K900 | And you can always refactor late | 14:04:29 |
K900 | * And you can always refactor later | 14:04:30 |
virtu | alright, thanks! | 14:04:37 |
cpcloud | a bunch of packages still require poetry-the-library but that seems to be removed in nixpkgs | 14:34:28 |
cpcloud | This is a bit of a problem, since it means we risk duplicate derivations | 14:34:52 |