Vamsi Avula

Another way to approach this would probably be a gobin "package manager" for go install ...s.

Looks like there are some selfupdate packages available but we could probably just run go install with the module from (debug) buildinfo? Need to handle devel binaries explicitly, though.

Maybe we could start a goroutine to check for updates and tie it back at the end (of the program)? Need to figure out a way to not do that...

FWIW, looks like grouping is not available across modules ATM (see https://github.com/dependabot/dependabot-core/issues/7547).

Or maybe --cpuprofile and --memprofile (see https://pkg.go.dev/runtime/pprof).

A snippet I used elsewhere, for posterity -- ``` assert.Nil(trace.Start(assert.Ok(os.Create("trace.out")))) assert.Nil(pprof.StartCPUProfile(assert.Ok(os.Create("cpu.prof")))) defer func() { trace.Stop() pprof.StopCPUProfile() runtime.GC() assert.Nil(pprof.Lookup("allocs").WriteTo(assert.Ok(os.Create("mem.prof")), 0)) }() ```

Doesn't look like isParallel is exposed but we can probably get away with simply calling Setenv?

If it helps anyone, https://github.com/avamsi/climate/commit/1e885331f91f822022fc069d30b63fbff2beb8b5#diff-4d7d1923693fc5ce892add2ea2907a744e77ea0b50c1939ccc5067cb48a466a3 is how I worked around this for a CLI framework I maintain (https://github.com/avamsi/climate, which is built on top of Cobra).

> What is the benefit of this approach over the much simpler idea of `jj util exec`? I think supporting functions in aliases (similar to how we already do it...

> What do you mean by that? How is it easier than using `$1` in bash? I should RTFM -- I didn't realize positional arguments work with `jj util exec`...