| 8 Jun 2024 |
 aprl | In reply to @k900:0upti.me
Can you get that done by next week? :) by next week, within one week, whats the challenge here exactly? | 15:05:47 |
 K900 | There is no actual challenge | 15:05:58 |
| K900 | The point is that rewriting Hydra and deploying a new solution would take a lot of time and effort | 15:06:10 |
| K900 | And while it should be done, it can't be done now | 15:06:21 |
 ⚠️ eldritch horrors operating in this area ⚠️ | In reply to @delroth:delroth.net
https://gerrit.lix.systems/c/lix/+/1418 I got annoyed at not being able to just use Lix as a flake with a recent nixpkgs version, please flame me if you think this shouldn't be done before Lix 2.90 is tagged :p if it doesn't affect in-nixpkgs builds we should probably defer until after tagging | 15:06:32 |
| aprl | In reply to @k900:0upti.me
The point is that rewriting Hydra and deploying a new solution would take a lot of time and effort 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 | 15:07:06 |
| 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 |
