| 3 Nov 2023 |
@vengmark2:matrix.org | GitHub is having a bad day: https://github.com/nix-community/poetry2nix/ and others are 404-ing. | 19:00:16 |
@vengmark2:matrix.org | * FYI GitHub is having a bad day: https://github.com/nix-community/poetry2nix/ and others are 404-ing. | 19:00:22 |
@vengmark2:matrix.org | * FYI GitHub is having a bad day: https://github.com/nix-community/poetry2nix/ and others are 404-ing. sed s/Compiling/GitHub is down/ https://xkcd.com/303/ | 19:02:39 |
@vengmark2:matrix.org | * FYI GitHub is having a bad day: https://github.com/nix-community/poetry2nix/ and others are 404-ing. sed 's/Compiling!/GitHub is down!/' https://xkcd.com/303/ | 19:03:05 |
| 4 Nov 2023 |
@tcarlsdyfis:matrix.org | I think there might have been a regression, at least when using slightly older nixpkgs? -- moving from poetry2nix 2023-09-22 to 2023-11-03, when setting preferWheel = true, I'm getting a failure on account of /pkgs/development/python-modules/wheel/default.nix not accepting flit-core as an argument. | 20:50:44 |
@tcarlsdyfis:matrix.org | ...hm; bisection puts that as introduced just after a nixpkgs repin (updating the version of unstable being used at 7a5a5730d289097c1046993541a2de1b40d6f6b5)... well. If NixOS-23.05 isn't supported, that does explain things. | 21:08:35 |
| 5 Nov 2023 |
K900 | Yeah, I don't think it's viable to support 23.05 and unstable on the same codebase anymore | 03:12:21 |
adisbladis | I'm pretty salty about it | 03:43:19 |
K900 | I don't like it very much | 03:44:08 |
K900 | But I also don't know how we can avoid it | 03:44:14 |
adisbladis | I'm also pretty salty about the nixpkgs removal | 03:44:24 |
adisbladis | Because I think now there are 0 sane ways to package python stuff in nixpkgs | 03:44:35 |
K900 | Without, like, making all the bootstrap overrides conditional on nixpkgs versions | 03:44:39 |
K900 | In reply to@adis:blad.is Because I think now there are 0 sane ways to package python stuff in nixpkgs I actually think that moving more stuff like this out of tree is good | 03:45:21 |
adisbladis | Yes and no.. | 03:45:52 |
adisbladis | Nixpkgs is stuck with it's crummy manual packaging, and I don't see any way to push any kinda sanity forward there | 03:46:27 |
K900 | Because that way we can just point at the out-of-tree thing and say "do you want to simply build your own thing? use that" | 03:46:38 |
K900 | In reply to@adis:blad.is Nixpkgs is stuck with it's crummy manual packaging, and I don't see any way to push any kinda sanity forward there I think there's value in unvendoring dependencies the way nixpkgs does | 03:47:04 |
adisbladis | We're stuck with poorly translating upstream package definitions to nix and losing fidelity in the process | 03:47:05 |
K900 | But I also don't think most people that just want to ship stuff should go that route | 03:47:20 |
adisbladis | In reply to @k900:0upti.me I think there's value in unvendoring dependencies the way nixpkgs does Absolutely, there is very different needs for packaging stuff out of tree and in tree | 03:47:48 |
K900 | Like, it's very much a distribution thing | 03:47:55 |
adisbladis | But like, why do we poorly translate pyproject.toml files into nix | 03:48:00 |
K900 | Because we can't do IFD well, mostly? | 03:48:17 |
K900 | Like I think pyproject.nix would be great in nixpkgs | 03:48:35 |
K900 | If we figure out a way to do IFD without exploding | 03:48:48 |
adisbladis | What I mean is, why is nixpkgs python packages not just a pyproject.toml dumped in tree | 03:48:51 |
adisbladis | In reply to @k900:0upti.me Like I think pyproject.nix would be great in nixpkgs It doesn't use IFD at all | 03:49:04 |
K900 | Well it would if the pyproject.toml comes from the upstream source | 03:49:17 |
adisbladis | What I mean is, instead of having a default.nix in tree we'd have pyproject.toml in tree | 03:49:27 |