Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gqlgen doesn't have a --version flag #182

Closed
hueys opened this issue Jul 10, 2018 · 9 comments
Closed

gqlgen doesn't have a --version flag #182

hueys opened this issue Jul 10, 2018 · 9 comments
Labels
help wanted Extra attention is needed

Comments

@hueys
Copy link

hueys commented Jul 10, 2018

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
Copy link
Collaborator

vektah commented Jul 14, 2018

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?

@vektah vektah added the help wanted Extra attention is needed label Jul 14, 2018
@cayter
Copy link

cayter commented Jul 14, 2018

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
Copy link
Collaborator

vektah commented Jul 15, 2018

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

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
Copy link
Member

mtibben commented Jul 15, 2018

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

@vektah
Copy link
Collaborator

vektah commented Jul 16, 2018

Theres a closed unresolved issue here golang/go#24051

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

@mtibben
Copy link
Member

mtibben commented Jul 16, 2018

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

@hueys
Copy link
Author

hueys commented Jul 16, 2018

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
Copy link
Collaborator

vektah commented Jul 16, 2018

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
Copy link
Author

hueys commented Jul 16, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants