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

PoC: Provide inputs as Nickel records #88

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

YorikSar
Copy link
Collaborator

@YorikSar YorikSar commented Jul 6, 2023

Generate Nickel record with all packages from each input and allow Nickel code to access them directly without declaring them in input_spec.

Generate Nickel record with all packages from each input and allow Nickel
code to access them directly without declaring them in `input_spec`.
@YorikSar
Copy link
Collaborator Author

YorikSar commented Jul 7, 2023

I've finally got this to somewhat work. Current limitations:

  • have to limit nixpkgs input to only supported pkgs because of Poor performance on importing big records tweag/nickel#1428 and hack Haskell subset with recurseForDerivations fields. It seems we'd either have to evaluate everything in nixpkgs or somehow pick paths that are the most interesting for us.
  • inputs are mixed into inputs field, it should be quite straightforward to add them to the lockfile, but then we'll need to pass it into builders.ncl somehow.
  • files should be generated in separate derivations so that we can cache them and not re-evaluate then every time. I've tried just running nix-instantiate --eval --offline --extra-experimental-features flakes --store ./store "''${nixSourcePath}" > $out with nixSource set to:
          let
            nickel-nix = (builtins.getFlake "${./.}");
            input = builtins.getFlake "${input}";
          in
            nickel-nix.lib.${system}.collectPkgs input
    but that yields sandbox related errors. Probably it won't be a huge deal if we generate these files when generating the lockfile.

@YorikSar
Copy link
Collaborator Author

With tweag/nickel#1428 fixed with reported 10x speedup, we could get back to evaluating this approach. It might be nicer to provide such records to users with the lockfile so that completion works fine with them. We could then also expand them with additional functionality like wrapping passthru functions where needed. What do you think @thufschmitt?

@thufschmitt
Copy link
Member

I would wait for 0.1 to be out as there's already a bit of work do be done first (besides the fact that we can't use the latest Nickel because of tweag/nickel#1664). But that would be great if it allows us to improve the Nix interop!

@yannham
Copy link
Contributor

yannham commented Jun 21, 2024

@YorikSar @thufschmitt what is the status of this PR? Is this work still relevant, but needs to be rebased, or can we just close it ?

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

Successfully merging this pull request may close these issues.

3 participants