gqlgen doesn't have a --version flag

[hueys]

Expected Behaviour

The gqlgen command line tool has a flag to print which version of gqlgen is being run.

Actual Behavior

As far as I can tell, there's not currently a way to see what version of gqlgen is being run.

[vektah]

I'm not sure if there is a good way to do this.

gqlgen is both a library and a binary and both need to be in sync, so there will probably never be published release binaries. There goes -X main.version=0.2.5 when building.

I could commit const version = "0.2.5", but I get the feeling it would be forever falling out of sync with reality.

Maybe it should probably be left up to dep/vgo/etc to answer this question.

Anyone have ideas?

[cayter]

I'm currently using dep to manage my dependencies and came up with a make build:gqlgen command via Makefile that builds gqlgen binary from the vendor folder. So far, it works fine for me. However, this will be a bit hassle if 1 has multiple projects that use different versions of gqlgen as they have to keep re-running make build:gqlgen whenever they need to use gqlgen binary.

[vektah]

Yeah there are a bunch of ways to run a command out of vendor.

• Makefile to build (might be hard to manage multiple projects with different versions if installing)
• use go run ../../vendor/github.com/vektah/gqlgen/main.go
• use gorunpkg github.com/vektah/gqlgen - https://gqlgen.com/getting-started/#finishing-touches
• virtual gopath per project https://github.com/GetStream/vg

They all have the same problem though, short of committing a version string I don't see a good way to get a version in there. I don't think dep even leaves the .git directory intact.

[mtibben]

^ This might be good feedback for @rsc while the go team is ironing out modules

[vektah]

Theres a closed unresolved issue here golang/go#24051

Looks like go modules might be a step backwards for pinning per-project binaries.

[mtibben]

Maybe the binary could check the project lock file / module file to compare its internal version vs the library version

[hueys]

I'd originally installed gqlgen using go get to use the binary, but have been using the library via dep. I'd filed this since I was running into issues where the version installed in vendor by dep would be newer than what was installed by go get.

I should probably just remove the version installed by go get and look into running the binary out of vendor. Then I can simply check the Gopkg.toml/lock files to determine the version.

[vektah]

Yeah, that's the approach I've recommended in the getting started guide.

Too many headaches when the binary and the lib fall out of sync.

[hueys]

Sounds good. If you want to leave this open to see if anyone else has better ideas, fine, if not, feel free to go ahead and close it.