gex's Introduction

gex

The implementation of clarify best practice for tool dependencies.

Features

Manage versions of tools dependencies, and build them with specified version
Does not introduce new mechanisms to manage tool dependencies
Only 2 commands that you use: --add and --build
All you need to execute go generate ./tools.go if you want only to use tools

Usage

`gex --add [packages...]`

Add a new tool to dependencies:

$ gex --add github.com/golang/mock/mockgen

The tool will be managed in tools.go and its version will be managed by Modules or dep.

$ cat tools.go
// Code generated by github.com/izumin5210/gex. DO NOT EDIT.

// +build tools

package tools

// tool dependencies
import (
        _ "github.com/golang/mock/mockgen"
)

// If you want to use tools, please run the following command:
//  go generate ./tools.go
//
//go:generate go build -v -o=./bin/reviewdog github.com/golang/mock/mockgen

$ cat go.mod | grep mock
        github.com/golang/mock v1.1.1 // indirect

`go generate ./tools.go`

Build executable binaries into $PWD/bin.

$ go generate ./tools.go

`gex [command] [args...]`

Execute command that managed in tools.go and go.mod. gex will build the executable binary automatically if needed.

$ gex mockgen
# prints mockgen's help text...

Installation

macOS

$ brew install izumin5210/tools/gex

Other platforms

You can download prebuilt binaries for each platform in the releases page.

Build from source

$ go get github.com/izumin5210/gex/cmd/gex

Requirements

gex depends on dep or Modules to manage tool dependencies,

gex's People

Contributors

Stargazers

Watchers

gex's Issues

Support executing commands in sub-directories

module-aware main command imports named awkwardly

Not 100% sure if this is specific to gex, or go modules binary tools more generally. If a tool has a top-level main binary and uses versioned module support, the naming pulls the version, not the library's name. For example:

gex --add https://github.com/maxbrunsfeld/counterfeiter/v6 adds https://github.com/maxbrunsfeld/counterfeiter as the binary v6. For subcommands they can be imported by their path, but since Counterfeiter's command is top-level - not nested under some name - that won't work reasonably.

In a non-module-aware context you can install counterfeiter as just https://github.com/maxbrunsfeld/counterfeiter without the v6 path, but trying to do gex --add https://github.com/maxbrunsfeld/counterfeiter/@v6.2.2 (for example) won't work because it is module aware - it says go.mod has post-v0 module path "github.com/maxbrunsfeld/counterfeiter/v6".

In any case, fully-namespanced versioned modules theoretically should support older and newer binaries coexisting; not sure if there's a good way to pull that one off.

Show warning when the adding package is not for command.

Now, gex can add packages which is not for command without any warnings.

# developers can add packages which is not for command
gex --add github.com/izumin5210/gex

# what developers really want to add
gex --add github.com/izumin5210/gex/cmd/gex

In this situation, developers cannot notice their mistake.
So, please implement to be able to show the warning.

Recommend Projects

izumin5210 / gex Goto Github PK