anchore
`path` subcommand
A significantly improved user experience could be unlocked by adding a binny path <tool> subcommand. This subcommand should operate on a single binary to verify it is available and return the full path to the binary.
This feature would unlock a much nicer usage pattern, where as long as you have binny, you can efficiently and reliably run commands across all systems and environments.
When coupled with these features:
- https://github.com/anchore/binny/issues/178
- https://github.com/anchore/binny/issues/28
- https://github.com/anchore/binny/issues/29
... it would unlock a simpler model, where usages become references to binny path instead of a user needing to understand the .tool directory or binaries picked up from the environment, especially in a Taskfile which normalizes some scripting such as pipes from commands, could work reliably cross-platform. Take this command as example:
UNIT_TESTS = $(shell $(GO) list ./... | grep -v /test/)
unit:
go test $(UNIT_TESTS)
... this summarily fails on Windows due to grep not being available, but almost every other platform has what we need. Maybe something like this would work across platforms:
GO = $(shell binny path go)
GREP = $(shell binny path grep)
UNIT_TESTS = $(shell $(GO) list ./... | $(GREP) -v /test/)
unit:
$(GO) test $(UNIT_TESTS)
... and especially in a Taskfile, since the shell is made more consistent:
unit:
cmds:
- cmd: "$(binny path go) test $($(binny path go) list ./... | $(binny path grep) -v /test/)"
... additionally, and maybe more importantly, since the path subcommand is only concerned with a single binary, things like bouncer, which has no Windows version wouldn't fail to be downloaded when a user runs make test, both making the execution faster and more robust.
