| 8 Jun 2024 |
 K900 | No one does' | 15:07:11 |
| K900 | * No one does | 15:07:12 |
| K900 | But deploying Hydra is still much easier than rewriting Hydra | 15:07:20 |
 aprl | I meant replacing Hydra with better tooling instead of rewriting it with same featureset | 15:07:39 |
| K900 | The featureset of Hydra is generally perfectly fine | 15:07:52 |
| K900 | It's the implementation that has issues | 15:07:59 |
| K900 | (and also this does not help the whole "time and effort" thing) | 15:08:24 |
 delroth | In reply to @aprl:uwu.is
my point is that deploying Hydra and configuring it and stuff is a pain in the butt and I dont know anyone who likes Hydra so much nobody's forcing you to deploy Hydra, I like Hydra because there's no other CI platform which can handle 200K individual build units getting evaluated every 6h and not just completely melt down | 15:09:24 |
| aprl | In reply to @k900:0upti.me
The featureset of Hydra is generally perfectly fine well yea I suppose.
I personally would just wish for a colmena level of ease of use for a new tooling | 15:09:27 |
| delroth | then don't use Hydra | 15:09:33 |
| K900 | I would too, that's not really the point | 15:09:41 |
| K900 | Like | 15:09:45 |
| K900 | My point isn't that Hydra is good | 15:09:57 |
| K900 | Or that we should keep Hydra long term | 15:10:01 |
| K900 | My point is that "rewrite Hydra" is not an answer to "how do we get something like Hydra now" | 15:10:12 |
| K900 | (the "now" being the important part) | 15:10:20 |
| aprl | In reply to @k900:0upti.me
My point is that "rewrite Hydra" is not an answer to "how do we get something like Hydra now" it wasnt supposed to be a answer | 15:10:33 |
| delroth | In reply to @pennae:matrix.eno.space
if it doesn't affect in-nixpkgs builds we should probably defer until after tagging I don't really get the rationale - this is a no-op for in-nixpkgs because it doesn't use any of those boehm gc patches, they're only used for flake/package.nix builds | 15:10:34 |
| delroth | meanwhile the consequence of this is that currently Lix can't be built with a nixpkgs >= 24.05 | 15:10:51 |
| delroth | and it would suck for that to also be the case for Lix 2.90 in my opinion, on top of it being really annoying to me right now | 15:11:08 |
| aprl | In reply to @k900:0upti.me
(the "now" being the important part) well yea, but Lix is just a nixcpp fork, so overlaying Lix as the Nixcpp for Hydra should solve all issues aint it? | 15:11:16 |
| K900 | It's not entirely compatible already | 15:11:30 |
| aprl | oh nvm then | 15:11:38 |
| K900 | And Hydra uses Nix internals extensively | 15:11:38 |
| aprl | In reply to @delroth:delroth.net
meanwhile the consequence of this is that currently Lix can't be built with a nixpkgs >= 24.05 reason why I had to disable it... cries in nixpkgs unstable | 15:12:10 |
| delroth | why aren't you using lix-project/nixos-module | 15:12:31 |
| aprl | I was | 15:12:40 |
| delroth | then you were not impacted by this | 15:12:48 |
| aprl | huh | 15:12:57 |
| aprl | it just stopped compiling and I had no time to bother | 15:12:59 |
