search

izumin5210 / gex

The implementation of "clarify best practice for tool dependencies".
MIT License
51 stars 5 forks source link

module-aware main command imports named awkwardly #28

Open ysamlan opened 5 years ago

ysamlan commented 5 years ago

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.

ysamlan commented 5 years ago

Seems like the same issue as https://github.com/myitcv/gobin/pull/70 .