amonks / run Goto Github PK

if so, what should the task browser look like? should it list the commands and stuff or just task names? if commands, what happens for non script-task implementations of Task? should Task have a Description()string method?

also, what happens if not-a-tty? it feels wrong for tty-ness to change the behavior a lot

this is easy enough to implement, but I don't want to add to the API surface unless there's a real use case

is there ever a good reason to have a cycle? maybe?

suggestion from @cgsdev0

can we hide them in the ui? or will they have some kind of output in the future?

this needs thought because taskfileTask is private and I don't really want to add it to the public API

in the meantime, there is a disabled print in taskfile.go for debugging, but that is helpful for me, not for users with large task systems

ty @cgsdev0 for the report

for scriptTasks, waiting 500ms (or whatever) and then marking the task "ready" is close to the best we can do; fine.

but that 500ms thingy should be part of script task, not part of the runner itself—if have some other task implementation, it can just… say when it's ready!

useful for -list in large tasksets, and maybe we can use them in other parts of the ui, too (eg #57)

thoughts:

• should be able to have nice multiline documentation, not just a short string
• short strings should work good too tho

matters for:

• the tui list sidebar
• the -list flag
• the task-not-found error
• Validate errors

i'm seeing some strange behavior when trying to set env vars on a task, pushed a branch with the example tasks referenced below: main...ecshreve:run:ecs/env-bug

tldr: i tried a few different things. and the only way im able to set an env var via the field on the task and have it persist in the task, results in the rest of my env disappearing

tasks:

[[task]]
  id = "simple"
  type = "short"
  cmd = """
    echo "hello world"
    echo "TESTENV: $TESTENV"
    env | head -n 10
    echo "done"
  """

[[task]]
  id = "simple-env"
  type = "short"
  env = { TESTENV="test" }
  cmd = """
    echo "hello world"
    echo "TESTENV: $TESTENV"
    env | head -n 10
    echo "done"
  """

[[task]]
  id = "simple-env-two"
  type = "short"
  env = [{ TESTENV="test" }]
  cmd = """
    echo "hello world"
    echo "TESTENV: $TESTENV"
    env
    echo "done"
  """

testing:

> run simple > run.log
> run simple-env >> run.log
> run simple-env-two >> run.log

> cat run.log
  simple  starting
          hello world
          TESTENV: 
          NVM_INC=/Users/eric/.nvm/versions/node/v16.16.0/include/node
          TERM_PROGRAM=vscode
          ABBR_TIPS_PROMPT=\n💡 \e[1m{{ .abbr }}\e[0m => {{ .cmd }}
          NVM_CD_FLAGS=
          SHELL=/opt/local/bin/fish
          TERM=xterm-256color
          FORGIT_INSTALL_DIR=/Users/eric/.config/fish/conf.d
          fzf_history_opts=--preview-window=top:4:wrap
          TMPDIR=/var/folders/m4/w2m5tqm924vg6l09py6zxld40000gn/T/
          TERM_PROGRAM_VERSION=1.81.0-insider
          done
          exit ok

     run  done
  simple-env  starting
              hello world
              TESTENV: test
              PWD=/Users/eric/github.com/run/example
              SHLVL=1
              TESTENV=test
              _=/usr/bin/env
              done
              exit ok

         run  done
  simple-env-two  starting
                  hello world
                  TESTENV: 
                  NVM_INC=/Users/eric/.nvm/versions/node/v16.16.0/include/node
                  TERM_PROGRAM=vscode
                  ABBR_TIPS_PROMPT=\n💡 \e[1m{{ .abbr }}\e[0m => {{ .cmd }}
                  NVM_CD_FLAGS=
                  SHELL=/opt/local/bin/fish
                  TERM=xterm-256color
                  FORGIT_INSTALL_DIR=/Users/eric/.config/fish/conf.d
                  fzf_history_opts=--preview-window=top:4:wrap
                  TMPDIR=/var/folders/m4/w2m5tqm924vg6l09py6zxld40000gn/T/
                  TERM_PROGRAM_VERSION=1.81.0-insider
                  done
                  exit ok

             run  done

Tasks can't take any input. Not flags, not stdin, not nothin else besides. One dogfoody use case for this would be a tag-and-release script for Run, which would require specifying a version identifier somehow.

"not run's purview" is a reasonable answer.

"tasks can declare structured inputs, which the UI can handle appropriately" might be a fun answer

the "run" output is really just "file watches" and "done", which isn't enough value to justify the space in the ui

options:

• rename it "file watches" and only show if there are watches; move "done" to stdout or something
• add more stuff! accumulate value!

I think I will sit on this for a while and see what accumulates.

I ran the following command from the README:

go install github.com/amonks/run@latest

I get this error using go 1.20.6:

package github.com/amonks/run is not a main package

this, however, did work for me:

go install github.com/amonks/run/cmd/run@latest

i'm a bit foggy on how go modules work, so I'm not sure if this is a me problem or an issue with the instructions in the README 😅

ty @cgsdev0 for the report

…or add the entire -help output to the readme?
…or get rid of the readme and generate it from -help?

this sort of feature is a staple of this sort of task running system, but adds a lot of user-facing complexity

• we'd need some persistent state between runs
• tasks would need to specify the files they depend on
• we'd need to dirhash those files and put them in the state
• we'd need to skip tasks if the hash hadn't changed

I feel like there's more complexity to this, but those steps are the obvious ones off the top of my head

just adding persistent state is a pretty significant change (not, like, difficult, but significant)

should probably make an abstraction for jumping around the pager…

seems like a lot of work