[Tracking Issue] Merging Hydra into Lix #56

New issue

Open

opened 2025-06-21 21:20:07 +00:00 by raito · 1 comment

raito commented

2025-06-21 21:20:07 +00:00

Owner

We would like to merge Hydra in the Lix monorepo, similarly to what is done to nix-eval-jobs.

Problem is that Hydra depends on Lix via the C++ unstable API AND the Perl bindings and merging it would make things messier for the ongoing RPC efforts.

A necessary and sufficient condition to make Hydra go into Lix is to:

Get rid of the Perl bindings and replace them with a proper RPC to perform store access, note that Perl does not have Cap'n'Proto implementations.
Remove all the re-implementations of the SSH protocol or the serve protocol and reuse the newly built RPC interfaces.

Once this is achieved, we can move Hydra inside Lix, in the meantime, I will help with getting Hydra up-to-date with Lix HEAD until we get closer to this goal.

We also need to announce that we plan to deprecate the Perl bindings.

cc @pennae @ma27

We would like to merge Hydra in the Lix monorepo, similarly to what is done to nix-eval-jobs. Problem is that Hydra depends on Lix via the C++ unstable API _AND_ the Perl bindings and merging it would make things messier for the ongoing RPC efforts. A necessary and sufficient condition to make Hydra go into Lix is to: - Get rid of the Perl bindings and replace them with a proper RPC to perform store access, **note** that Perl does not have Cap'n'Proto implementations. - Remove all the re-implementations of the SSH protocol or the serve protocol and reuse the newly built RPC interfaces. Once this is achieved, we can move Hydra inside Lix, in the meantime, I will help with getting Hydra up-to-date with Lix HEAD until we get closer to this goal. We also need to announce that we plan to deprecate the Perl bindings. cc @pennae @ma27

ma27 commented

2025-06-22 08:10:17 +00:00

Member

Remove all the re-implementations of the SSH protocol or the serve protocol and reuse the newly built RPC interfaces.

I said it before (#50 (comment) and multiple times at GPN), so most of you this will be boring, but to have it documented in the correct ticket: I do plan to kill the custom SSH/serve protocol with fire, the only open question is on what codebase.

Option a is that the Helsinki queue runner turns out to be a viable option (I dearly hope this will be the case) and we can build on top of it and replace their RPC with Capn-proto -- which is the part we'll have to maintain by ourselves in this fork.

Option b is -- as fallback -- to keep the current implementation and do it there.

> Remove all the re-implementations of the SSH protocol or the serve protocol and reuse the newly built RPC interfaces. I said it before (https://git.lix.systems/lix-project/hydra/issues/50#issuecomment-12486 and multiple times at GPN), so most of you this will be boring, but to have it documented in the correct ticket: I do plan to kill the custom SSH/serve protocol with fire, the only open question is on what codebase. Option a is that the Helsinki queue runner turns out to be a viable option (I dearly hope this will be the case) and we can build on top of it and replace their RPC with Capn-proto -- which is the part we'll have to maintain by ourselves in this fork. Option b is -- as fallback -- to keep the current implementation and do it there.

No labels

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/hydra#56

No description provided.

Rows
Columns