[chalsprhebaodu]

I am thrilled to hear that this effort exists.

What’s the rationale for the heavy use of tagged template literals in the API? From the outside, it seems like an esoteric choice that makes ergonomics slightly worse, less approachable, and less idiomatic. This seems to fly directly in the face of the goals of this project.

All that said, I could be convinced that the API choice isn’t a mistake.

At any rate, I’m excited to see where this project goes.

[jkarni]

It’s to allow interpolation of packages and environments. But in practice we don’t use it that often, so we were thinking of switching the main function to using just a second string argument. (In other words, I agree.)

[chalsprhebaodu]

That seems reasonable! I can’t really locate any examples of that functionality. Could you show me what that would look like?

[soenkehahn]

One working example is this:

  import * as garn from "https://garn.io/ts/v0.0.14/mod.ts";
  import * as pkgs from "https://garn.io/ts/v0.0.14/nixpkgs.ts";

  export const main: garn.Executable = garn.shell`${pkgs.jq}/bin/jq --version`;

Put that in a 'garn.ts' file and run 'garn run main' and you should see the version of 'jq' that you can get from our 'nixpkgs' module.

But yeah, I completely agree with the sentiment here. This is a rather cumbersome syntax to support a use-case that we don't even have examples for. So clearly the normal usage shouldn't force you to use template strings.

[chalsprhebaodu]

I can definitely the utility of it.

Perhaps a standalone function (like nixRaw) could work to enable this.