Skip to content

path subcommand #179

@kzantow

Description

@kzantow

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:

... 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions