dependencies evaluated at runtime

[gedw99]

https://github.com/gedw99/datastar

https://github.com/gedw99/datastar/blob/main/Taskfile_tool.yml works for managing compile time dependencies. For example this var:

{{.JQ_BIN_NAME}}

But I have a dependency here https://github.com/gedw99/datastar/blob/main/Taskfile.yml#L16, which causes all the code to not evaluate, because it needs the binary jq ( aka {{.JQ_BIN_NAME}} ) to be physically installed.

SO I have a catch 22. I can't run "task tool:print" in order to install the binary, because the binary in not installed and breaks any code that relies on the the binary being installed.

task tool:print
"-r": executable file not found in $PATH
task: Command "cat library/package.json |  -r .version" failed: exit status 127

is there a workaround that anyone can suggest ?

The Makefile can do this sort of thing without blowing up: https://github.com/gedw99/datastar/blob/main/tools.mk

[gedw99]

Actually it seems the core issue here is that the sh command does not seem to behave like it does in a terminal.

Here it does the right thing:

which gojq
gojq not found

task tool:print  
task: Command "which gojq" failed: exit status 1

If "task tool:print " returned a "gojq not found" instead of an error than it might be easier to overcome this catch 22 ?

[pd93]

Before I address your question, I want to make a general suggestion for when you want to find the path to an executable. It is recommended to use command -v <cmd> instead of which <cmd>. I won't go into details here, but here's a link to a post on StackExchange which outlines some of the reasons why this is the case.

---

That aside, if you want Task not to error when setting a variable dynamically, you can use the | true trick that is commonly used in shell programs. For example:

vars:
  JQ_BIN_NAME: "gojq"
  JQ_BIN_WHICH:
    sh: 'command -v {{.JQ_BIN_NAME}} | true'

In this scenario, the value of JQ_BIN_WHICH will be "" which I believe is all the Makefile you attached is doing? This might not actually be what you want though as you're still going to run into issues later when attempting to run a command.

---

A couple of options for you:

1. Skip gojq entirely and just use the built-in fromJson function:

vars:
  PACKAGE:
    sh: cat library/package.json
  VERSION: '{{(fromJson .PACKAGE).version}}'

This might not be practical in scenarios where you need to do something more complex that just accessing a JSON field. gojq and similar tools can do some pretty crazy things.

2. Don't install/use tools globally. I use this pattern commonly in a few of my projects - In fact, Task itself does this:

version: '3'

vars:
  BIN: "{{.ROOT_DIR}}/bin"

tasks:
  foo:
    deps: [install:gojq]
    cmds:
      - '{{.BIN}}/gojq --help'

  install:gojq:
    vars:
      GOJQ_VERSION: v0.12.14
    env:
      GOBIN: "{{.BIN}}"
    status:
      - go version -m {{.BIN}}/gojq | grep github.com/itchyny/gojq | grep {{.GOJQ_VERSION}}
    cmds:
      - go install github.com/itchyny/gojq/cmd/gojq@{{.GOJQ_VERSION}}

This pattern has a few advantages:

• It doesn't overwrite the system tools/versions that a user has installed.
• It ensures that the tool is always installed before running any command, but won't install it again unless you change the version variable (Some nice magic with go version -m here).
• No need to do system lookups for binaries. You always know where they are

[gedw99]

Thankyou for all that knowledge . There are things that are all best practices and so will modify my code to follow this.

Nice of you to take the time to explain this in detail

[gedw99]

This sort of stuff really should be in the docs or examples. I tried a few time to make the move from make to task and hit these problems that are described above...

[gedw99]

Hey @pd93

The other common pattern missing is sniffing the inane to decide what to do per OS and ARCH ?