| 25 Oct 2023 |
 K900 | And another one for nixops | 22:47:36 |
| K900 | Fuck my life | 22:47:38 |
 cpcloud | I eventually gave up on source builds and have been happily using preferWheels = true; | 22:49:58 |
| cpcloud | Things are just much much more pleasant that way | 22:50:06 |
| 26 Oct 2023 |
| cpcloud | Attempt at removing getCargoHash: https://github.com/nix-community/poetry2nix/pull/1371 | 12:34:47 |
| K900 | That's IFD | 12:54:35 |
| cpcloud | Darn | 13:37:54 |
| cpcloud | Wait, how? | 13:38:30 |
| cpcloud | Because of runCommand? | 13:39:35 |
| K900 | Because importCargoLock is eval time | 13:39:58 |
| K900 | It'll make a separate FOD for every dependency crate | 13:40:40 |
| cpcloud | It looks like we're already using import cargo lock in at least one place iirc | 14:16:08 |
| cpcloud | Does that need to be changed? | 14:16:19 |
| K900 | If we're not vendoring the Cargo.lock, yes | 14:19:43 |
| K900 | Yeah | 14:20:24 |
| K900 | Those are also IFD | 14:20:26 |
| K900 | But also, now that we're about to not be in nixpkgs anymore, maybe we should just give up | 14:20:38 |
| K900 | And allow IFD by default | 14:20:42 |
| K900 | It will solve most of the Cargo.lock issues and it will also solve most of the buildsystem overrides because we can just look at the pyproject.toml | 14:21:00 |
| cpcloud | Being able to look at build systems would be realllllly nice | 14:22:25 |
 schmittlauch (he/him) | Hm, removing legacyPackages.poetry2nix from the flake in the latest update broke my setup after re-locking. Not too bad to fix, but unexpected. I guess I ended up with that legacyPackages reference in the first place due to starting with a generic python template that took poetry2nix` from the nixpkgs input, and then transitioned to using the poetry2nix flake. | 21:08:44 |
| schmittlauch (he/him) | For reproducing https://github.com/nix-community/poetry2nix/issues/1351 with the latest master HEAD, I am struggling a bit to rework my flake to use poetry2nix. How do I now get the poetry2nix builders like mkPoetryEnv? | 21:21:35 |
| schmittlauch (he/him) | The template uses
let
# see https://github.com/nix-community/poetry2nix/tree/master#api for more functions and examples.
pkgs = nixpkgs.legacyPackages.${system};
inherit (import poetry2nix { inherit pkgs; }) mkPoetryApplication;
but I do not fully understand how this works in the background. Does this utilise the overlay output of the poetry2nix flake? | 21:23:00 |
| K900 | import poetry2nix { inherit pkgs; } | 21:23:06 |
| K900 | No | 21:23:14 |
| K900 | It just creates an instance of poetry2nix that's not overlayed anywhere | 21:23:34 |
| K900 | It's standalone | 21:23:36 |
| schmittlauch (he/him) | Is poetry2nix specified as an output of that flake? | 21:23:59 |
| schmittlauch (he/him) | Or how is it exposed as a name/ attr? | 21:24:16 |
| K900 | No, poetry2nix is the flake input | 21:24:19 |
