Search for imports in NICKEL_PATH

[jneem]

Here is a proposal for the most basic kind of "package management": a NICKEL_PATH environment whose value is a comma-separated list of paths look for imports in. The idea is that if you're using npm, for example, then you set this up to point to node_modules and then nickel can find all your imported packages.

It works reasonably well with nix also, as long as there are no recursive dependencies. For example, I'm using the following flake to get nickel validation for helix configurations:

{
  description = "Helix and nickel";

  inputs = {
    helix-nickel.url = "github:jneem/helix-nickel";
    nickel.url = "github:tweag/nickel/nickel-path";
  };

  outputs = { self, nixpkgs, helix-nickel, nickel }:
  let pkgs = import nixpkgs {
      system = "x86_64-linux";
    };
  in
  {
    devShell.x86_64-linux = pkgs.mkShell {
      NICKEL_PATH = helix-nickel.packages.x86_64-linux.default;

      nativeBuildInputs = [
        nickel.packages.x86_64-linux.default
      ];
    };
  };
}

I didn't have a good idea for how to test this, given that it requires setting up an environment variable...

[vkleen]

I feel like this should rather be an argument to Cache::new and then the actual logic from where to get the path should be up to the particular use case.

[jneem]

Putting this in Cache::new required threading them through a lot of things, so I tried out making the import paths mutable after construction. This changes the behavior a little, but I think it might be desirable actually: when running nix export file.nix, the path "file.nix" is now only searched for in the current directory, and NICKEL_PATH is only used for finding things that "file.nix" imports.

Edit: also, this will make tests easier to write. I'll add those when I have a little more time. (done)

[yannham]

Naive question: is there any rationale behind using an environment variable versus a CLI argument --nickel-path? Or versus using both? (whatever is the answer, it can be treated in a separate PR anyway)

[jneem]

I think probably it makes sense to have both. Maybe @thufschmitt will have an opinion, since I think he's the one that asked for the env var originally.

[thufschmitt]

Oh my! This is awesome, it means that we can get rid of the nickel lockfile in Organist.

I'm personally mostly interested in the environment variable, but a CLI flag would probably make sense for a number of use-cases.

[uhlajs]

This is great! We already have a PoC for nickel-lang/rules_nickel/, which adds imports keyword to nickel_export (similar to py_binary.imports). By doing this, we are able to eliminate the ugly relative path references in our imports.