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

Deprecate gqlgen Binary #415

Open
mathewbyrne opened this Issue Nov 6, 2018 · 6 comments

Comments

Projects
None yet
5 participants
@mathewbyrne
Collaborator

mathewbyrne commented Nov 6, 2018

Currently we ship a binary with gqlgen, but increasingly we're running into several issues with it:

  1. Bootstrapping is hard — we want to update the getting started docs to remove the go get usage, but then how do you run gqlgen in your project?

  2. Versioning differences — the getting started docs switch to using dep by their end, but this will cause issues if master is ahead of the latest release.

  3. Shipping Plugins — this becomes a lot harder since we need some way to load code dynamically from a fixed binary. We'd rather avoid trying to solve this by letting users roll their own binary anyway.

We're attempting to address the getting started issues at the moment with documentation, but we'd also like to make this code change at the same time. So starting from the next release out recommendation will be that you integrate gqlgen into your project by calling a new method in the cmd package. The documentation will be updated to reflect this.

This approach isn't set in stone yet, and I'm open to any other suggestions people might have. We've already seen a few projects do something similar, calling into the codegen package to have a custom binary.

@MichaelMure

This comment has been minimized.

MichaelMure commented Nov 6, 2018

Can't agree enough. I hacked my way into this approach by copy/pasting internal code from gqlgen (see https://github.com/MichaelMure/git-bug/blob/master/graphql/gen_graphql.go), it works really well, no risk of version mismatch and go dep will vendor anything that might be required.

That said, why the cmdpackage ? Intuitively, this package should be for a command line tool, not for package that you import and use. Why not simply the codegen package or even the root gqlgen package ?

@vektah

This comment has been minimized.

Collaborator

vektah commented Nov 6, 2018

We want to make sure there are no breaking changes here, so once someone copies the stub in they should only need to change it again if they want to add a plugin.

Secondly, we need to expose at least two commands, init and generate. Maybe we can package up init separately or get users to write a second entry point but it's additional work, and more surface area makes forward compatibility harder.

We also thought about changing the root package, but it would be a breaking change for everyone currently using gqlgen.

We should still make programmatic access to codegen a little cleaner, but we are focusing on improving the bootstrapping process which currently generates a few recurring issues (and probably causes some level of abandonment too)

@icco

This comment has been minimized.

icco commented Nov 6, 2018

Worth mentioning that whatever the solution is, it should work for people who use 1.11's go mod outside of the GOPATH as well, which the current solution doesn't.

I personally always found the binary confusing, and much preferred just using go generate

@mathewbyrne

This comment has been minimized.

Collaborator

mathewbyrne commented Nov 7, 2018

@icco that wont be addressed here, but you will note that the updated getting started guide in #416 adds a box-out note that we don't currently support Go Modules. Proper support is tracked in #226

@emil-nasso

This comment has been minimized.

emil-nasso commented Nov 11, 2018

I documented my (somewhat brute) approach to getting a working gqlbinary in issue #384 . No go get usage at all. Would very much like to know if there are any issues with my approach.

@mathewbyrne

This comment has been minimized.

Collaborator

mathewbyrne commented Nov 11, 2018

@emil-nasso nice job, that will get you across the line currently. The main issue you might eventually run into with your approach is that we may remove the func main() in the gqlgen package in the future and your go build command would stop working.

#416 has a new getting started document that also works without go get or gorunpkg. We will get this merged soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment