Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support nix >2.19 #49

Open
raboof opened this issue Jan 9, 2025 · 1 comment
Open

support nix >2.19 #49

raboof opened this issue Jan 9, 2025 · 1 comment

Comments

@raboof
Copy link
Collaborator

raboof commented Jan 9, 2025

Our rust utilities currently rely on a libnixstore from harmonia, which links against nix_2_19.

This means the lila utilities work on nixos 24.05 but no longer on nixos-unstable, which since dropped 2.19

Unfortunately, harmonia has since removed the libnixstore component, so upgrading harmonia is not a solution.

There's several ways to resolve this situation:

  • extract the relevant bits of libnixstore (that targets nix libstore via C++ code) into our utilities
  • extract libnixstore from before it was removed from harmonia and maintain it (and publish to crates.io) independently
  • extend the nix C API to support the bits we need (similar to C API: nix_store_open doc, add storedir, real_path NixOS/nix#12044), and then use FFI with that C API from our utilities

The last approach seems most attractive, as the C API will longer-term also be the basis for other bindings. We may be able to use/extract Rust bindings to the C API from nixops4

The APIs relevant to us appear to be:

  • hash_path
  • query_path_info
  • sign_string
  • Radix::Base32
  • query_references
@JulienMalka
Copy link
Owner

I am also more favorable on binding to the C API because it is supposed to be stable and will thus require less maintenance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants