lix compat: Hash::to_string removal #100

benaryorg · 2026-08-25T03:03:51Z

benaryorg commented

2026-08-25 03:03:51 +00:00

Lix recently removed the Hash::to_string API.
The replacement to_base16() API however is equivalent to to_string(HashFormat::Base16, true) while this code uses false as the second parameter, which would embed the type in the resulting string.
Manually encoding the base16 string from the underlying hash type is possible however, as it is exposed by the Hash type.

Flake lock file updates:

• Updated input 'lix':
    'git+https://git.lix.systems/lix-project/lix?ref=refs/heads/main&rev=832932838bac4e4735025f3e6f13e5e856d94a70' (2026-08-14)
  → 'git+https://git.lix.systems/lix-project/lix?ref=refs/heads/main&rev=562630e26e4e459193a4769a16239d16084bca4a' (2026-08-22)
• Updated input 'nixpkgs':
    'github:NixOS/nixpkgs/02e08985a27c65ffd33d434eeb2e660a2e4dc84d' (2026-08-14)
  → 'github:NixOS/nixpkgs/a3b98866eecd08edac6e61a3081e69540a35020f' (2026-08-23)

Commit message above (semi-)verbatim.

Fixes #99

Lix recently removed the `Hash::to_string` API. The replacement `to_base16()` API however is equivalent to `to_string(HashFormat::Base16, true)` while this code uses `false` as the second parameter, which would embed the type in the resulting string. Manually encoding the base16 string from the underlying hash type is possible however, as it is exposed by the `Hash` type. Flake lock file updates: ```text • Updated input 'lix': 'git+https://git.lix.systems/lix-project/lix?ref=refs/heads/main&rev=832932838bac4e4735025f3e6f13e5e856d94a70' (2026-08-14) → 'git+https://git.lix.systems/lix-project/lix?ref=refs/heads/main&rev=562630e26e4e459193a4769a16239d16084bca4a' (2026-08-22) • Updated input 'nixpkgs': 'github:NixOS/nixpkgs/02e08985a27c65ffd33d434eeb2e660a2e4dc84d' (2026-08-14) → 'github:NixOS/nixpkgs/a3b98866eecd08edac6e61a3081e69540a35020f' (2026-08-23) ``` --- Commit message above (semi-)verbatim. Fixes #99

benaryorg added 1 commit

2026-08-25 03:03:52 +00:00

lix compat: Hash::to_string removal 148d9e60d3

Lix has introduced `Hash::to_base16` recently, and removed the `Hash::to_string` API.

Flake lock file updates:

• Updated input 'lix':
    'git+https://git.lix.systems/lix-project/lix?ref=refs/heads/main&rev=832932838bac4e4735025f3e6f13e5e856d94a70' (2026-08-14)
  → 'git+https://git.lix.systems/lix-project/lix?ref=refs/heads/main&rev=562630e26e4e459193a4769a16239d16084bca4a' (2026-08-22)
• Updated input 'nixpkgs':
    'github:NixOS/nixpkgs/02e08985a27c65ffd33d434eeb2e660a2e4dc84d' (2026-08-14)
  → 'github:NixOS/nixpkgs/a3b98866eecd08edac6e61a3081e69540a35020f' (2026-08-23)

Signed-off-by: benaryorg <binary@benary.org>

benaryorg requested review from ma27

2026-08-25 16:55:03 +00:00

pennae requested changes

2026-08-28 10:26:09 +00:00

Dismissed

pennae left a comment

heya, thank you! we're not entirely confident this change is safe because we don't know hydra enough to gauge how that hash column could ever be used, but it's not far off from equivalent either.

and since you seem quite on top of hydra and lix head both, would you perhaps also be interested in more formally helping out with hydra? :)

heya, thank you! we're not *entirely* confident this change is safe because we don't know hydra enough to gauge how that hash column could ever be used, but it's not far off from equivalent either. and since you seem quite on top of hydra and lix head both, would you perhaps also be interested in more formally helping out with hydra? :)

src/hydra-queue-runner/hydra-queue-runner.cc Outdated

					
				@ -541,3 +541,3 @@

				             product.subtype,

				             product.fileSize ? std::make_optional(*product.fileSize) : std::nullopt,

				             product.sha256hash ? std::make_optional(product.sha256hash->to_string(HashFormat::Base16, false)) : std::nullopt,

				             product.sha256hash ? std::make_optional(product.sha256hash->to_base16()) : std::nullopt,

that's not quite equivalent; the old code did not include the hash type in the string while this one would. it'll probably work anyway, but since the column is already named after the hash type there's no harm in doing somthing like base16Encode(*product.sha256Hash) instead?

that's not quite equivalent; the old code did not include the hash type in the string while this one would. it'll probably work anyway, but since the column is already named after the hash type there's no harm in doing somthing like `base16Encode(*product.sha256Hash)` instead?

You are absolutely correct, I totally missed the hash type prefix.
Is there any difference between using base16Encode(*product.sha256hash) and base16Encode(product.sha256hash.as_span())?
Since the to_base16() method uses as_span() I'd be inclined to use that one if there's no meaningful difference otherwise.

I've amended the PR with the * version for now.

You are absolutely correct, I totally missed [the hash type prefix](https://git.lix.systems/lix-project/lix/src/commit/f303b7d7263ddf9f5d284e3b0844efa427e16619/lix/libutil/hash.cc#L37). Is there any difference between using `base16Encode(*product.sha256hash)` and `base16Encode(product.sha256hash.as_span())`? Since the `to_base16()` method uses `as_span()` I'd be inclined to use that one if there's no meaningful difference otherwise. I've amended the PR with the `*` version for now.

Is there any difference between using base16Encode(*product.sha256hash) and base16Encode(product.sha256hash.as_span())?

if you mean base16Encode(product.sha256hash->as_span()), nope, those do exactly the same thing. hashes automatically convert to spans when used as such for convenience and to emulate Deref<Target = [u8]> you get in rust digests. we prefer to not use as_span because we think it's clearer, but that's just preference

> Is there any difference between using base16Encode(*product.sha256hash) and base16Encode(product.sha256hash.as_span())? if you mean `base16Encode(product.sha256hash->as_span())`, nope, those do exactly the same thing. hashes automatically convert to spans when used as such for convenience and to emulate `Deref<Target = [u8]>` you get in rust digests. we prefer to not use `as_span` because we think it's clearer, but that's just preference

benaryorg marked this conversation as resolved

benaryorg force-pushed lix-to_string from 148d9e60d3 to efbfdf82f7

2026-08-29 18:13:47 +00:00

Compare

benaryorg commented

2026-08-29 18:18:57 +00:00

and since you seem quite on top of hydra and lix head both, would you perhaps also be interested in more formally helping out with hydra? :)

I just have a Hydra instance running which builds Lix and Hydra with the latest version of nixpkgs' stable and unstable branches.
Neither am I well versed in C++, nor do I have a deep understanding of Hydra internals.
I'm also perpetually burnt out, so while I would absolutely want to help out more, it's just not possible at the moment (and my situation doesn't look like it's going to change anytime soon).
Sorry

> and since you seem quite on top of hydra and lix head both, would you perhaps also be interested in more formally helping out with hydra? :) I just have a Hydra instance running which builds Lix and Hydra with the latest version of *nixpkgs*' stable and unstable branches. Neither am I well versed in C++, nor do I have a deep understanding of Hydra internals. I'm also perpetually burnt out, so while I would absolutely want to help out more, it's just not possible at the moment (and my situation doesn't look like it's going to change anytime soon). Sorry :neocat_sad:

pennae approved these changes

2026-08-29 18:28:18 +00:00

pennae commented

2026-08-29 18:30:49 +00:00

@benaryorg wrote in #100 (comment):

I just have a Hydra instance running which builds Lix and Hydra with the latest version of nixpkgs' stable and unstable branches. Neither am I well versed in C++, nor do I have a deep understanding of Hydra internals. I'm also perpetually burnt out, so while I would absolutely want to help out more, it's just not possible at the moment (and my situation doesn't look like it's going to change anytime soon). Sorry

that's absolutely fine. thank you for all your help regardless, and we hope things improve for you despite everything

@benaryorg wrote in https://git.lix.systems/lix-project/hydra/pulls/100#issuecomment-19842: > I just have a Hydra instance running which builds Lix and Hydra with the latest version of _nixpkgs_' stable and unstable branches. Neither am I well versed in C++, nor do I have a deep understanding of Hydra internals. I'm also perpetually burnt out, so while I would absolutely want to help out more, it's just not possible at the moment (and my situation doesn't look like it's going to change anytime soon). Sorry :neocat_sad: that's absolutely fine. thank you for all your help regardless, and we hope things improve for you despite everything :dragnheart:

1

vriska approved these changes

2026-08-29 23:19:13 +00:00

vriska referenced this pull request from a commit

2026-08-29 23:20:41 +00:00

Merge pull request 'lix compat: Hash::to_string removal' (#100) from benaryorg/hydra:lix-to_string into main

vriska manually merged commit 962eaac8d1 into main

2026-08-29 23:21:03 +00:00

benaryorg commented

2026-08-30 04:48:02 +00:00

Thanks everyone for the feedback and review!

Just as a quick side note for anyone stumbling on this; OIDC Lite seems to be broken on both nixos-unstable and nixos-26.05 right now, so if Hydra doesn't build due to a dependency failure for you, that's probably why.
Last known good commit on my end for nixos-26.05 is a3b98866eecd, nixos-unstable at 56c02bc00adc (in case it helps).

Thanks everyone for the feedback and review! Just as a quick side note for anyone stumbling on this; [*OIDC Lite* seems to be broken](https://hydra.cloud.bsocat.net/build/1264701) on both *nixos-unstable* and *nixos-26.05* right now, so if Hydra doesn't build due to a dependency failure for you, that's probably why. Last known good commit on my end for *nixos-26.05* is `a3b98866eecd`, *nixos-unstable* at `56c02bc00adc` (in case it helps).

Sign in to join this conversation.

No reviewers

No labels

No milestone

No project

No assignees

3 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!100

Rows
Columns