Include a dash -v flag on the counterfeiter command about counterfeiter

[tjarratt]

Hey @zachgersh this is totally something I've wanted before.

Are you interested in submitting a PR for this?

[zachgersh]

Sure, did the SHA as version sound good or did we want to go with something else?

On Apr 8, 2016, at 12:46 AM, Tim Jarratt [email protected] wrote:

Hey @zachgersh this is totally something I've wanted before.

Are you interested in submitting a PR for this?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[tjarratt]

If that's expedient and makes the tool still work with "go get" then that's good for me.

Sent From A Very Small Keyboard

On Apr 8, 2016, at 06:57, Zach Gershman [email protected] wrote:

Sure, did the SHA as version sound good or did we want to go with something else?

On Apr 8, 2016, at 12:46 AM, Tim Jarratt [email protected] wrote:

Hey @zachgersh this is totally something I've wanted before.

Are you interested in submitting a PR for this?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[odlp]

It'd be great to see this version flag added. Our team is struggling with having different versions on Counterfeiter on different machines (and subsequently the different behaviour between versions as the tool evolves).

One approach could be using -ldflags during the build, as detailed in this blog post. This could be populated with the git SHA. The difficulty in this approach is how to populate these arguments when a user is running go get. Does anyone know if golang has a mechanism to default build args?

Alternatively, could the version info could be committed in the source code and incremented per release? Like this example.

I'd be happy to help out with this. Is there a preference on the direction?

[chendrix]

Yes please

[chendrix]

I think making releases of counterfeiter more often, and attaching binaries to the github release could help alleviate this.

If we change the distribution mechanism from go get to downloading a binary from github, we can better handle versioning schemes, and provide actual versioning for counterfeiter.

[odlp]

@chendrix That sounds good. If the version number is committed in the source it wouldn't prevent people from using go get if they still wanted to.

[joefitzgerald]

Given that counterfeiter is now a go module, and we plan to use semver and tags to release versions, I believe this issue is solved. There is an approach using tools.go that permits you to have take a module dependency on the tools your project uses, so that you can have reproducibility across machines.

Excerpt from golang/go#27653:

# create a new module
cd $(mktemp -d)
mkdir hello
cd hello
go mod init example.com/hello

# set GOBIN as a module-local install target
export GOBIN=$PWD/.bin

# update my PATH accordingly (I actually use https://github.com/cxreg/smartcd for this)
export PATH=$GOBIN:$PATH

# add a tool dependency (by definition, category 1 tool) following "best practice" laid out in 
# https://github.com/golang/go/issues/25922#issuecomment-412992431
cat <<EOD > tools.go
// +build tools

package tools

import (
        _ "golang.org/x/tools/cmd/stringer"
)
EOD

# install the tool
go install golang.org/x/tools/cmd/stringer

# verify we are using the module-local binary
which stringer

# which gives something like:
# /tmp/tmp.Hh0BNOF6k2/hello/.bin/stringer