Skip to content

Use Go Tool directives instead of "make install-tools" #782

Description

@IngwiePhoenix

Is your feature request related to a problem? Please describe.
I am testing wether this could work on FreeBSD so I am poking around the build system and found the "install-tools" target. The problem is that go install installs them globally, possibly overwriting existing versions in the user's GOBIN.

This can be solved by using the Go tool directive.

Describe the solution you'd like
Drop the taget and instead:

go get -tool github.com/vektra/mockery/cmd/mockery@v1.1.2
go get -tool github.com/uw-labs/lichen@v0.1.7
go get -tool golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest
go get -tool github.com/observiq/amazon-log-agent-benchmark-tool/cmd/logbench@ecfeca6c7554
go get -tool github.com/goreleaser/goreleaser@v1.6.3
go get -tool github.com/securego/gosec/v2/cmd/gosec@v2.10.0
go get -tool github.com/mgechev/revive@v1.2.0

(This inadvertedly updates a few dependencies.)

Now, tools can be accessed via go tool - for example, go tool lichen. This pins versions of used tools, project-local. :)

Some more useful info: https://blog.howardjohn.info/posts/go-tools-command/

Describe alternatives you've considered
go build -o <name> <pkg> should be able to build a local copy and output it into a local directory instead. It does however also mean that it's a little more cluttered. go run <pkg> would also work.

Additional context
I came across this project while planning how to best ship logs across all the platforms I use. So far, I like what I see - hence why I am trying things out! :)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions