Go 1.7 uses import "context"

[puellanivis]

If you're using the new "context" library, then gRPC servers can't match the server to the interface, because it has the wrong type of context.

Compiling bin/linux.x86_64/wlserver

asci/cs/tools/whitelist/wlserver

./wlserver.go:767: cannot use wls (type _Server) as type WhitelistProto.GoogleWhitelistServer in argument to WhitelistProto.RegisterGoogleWhitelistServer:
*Server does not implement WhitelistProto.GoogleWhitelistServer (wrong type for Delete method)
have Delete(context.Context, *WhitelistProto.DeleteRequest) (_WhitelistProto.DeleteReply, error)
want Delete(context.Context, _WhitelistProto.DeleteRequest) (_WhitelistProto.DeleteReply, error)

[iamqizhao]

1.7 has not been released. Let's worry about it later.

[puellanivis]

They have however released a beta test already. The whole idea behind pre-release versions is so that people can ensure compatibility for when it is released.

It's not like pulling context into the standard library is going to change. And whatever the eventual solution put into grpc is, it will still have to accommodate both Go 1.6.x and Go 1.7…

So, why not have the bug open but lower priority, and maybe someone could work on it occasionally ahead of Go 1.7 is released at which point, this bug becomes a significantly bigger priority, and would just have to be reopened/refiled anyways. I mean, release is scheduled for August, two months-ish away.

Why would you close this bug, when it's just going to be reopened two months from now?

[iamqizhao]

Because this will be buried in a lot of other things after 2 months and some ppl will create a new one (most ppl won't check if there is a duplicate already) when 1.7 is released and we need to dig out this "old" one and mark the new one "duplicated"...

I do not mind reopening this if you want anyways...

[puellanivis]

Maybe it's just the SRE in me, but I think projects should be prepared for change, rather than scramble once things are on fire.

We know this change is going to happen, and it has basically been on the horizon for a long time already. So, why not do something about it now?

Fix a bug before the vast majority of people even have a chance to file a ton of duplicate bugs? Priceless.

[iamqizhao]

Feel free to contribute.

[puellanivis]

Yeah, I'm thinking of how one could go about making it work for both golang.org/x/net/context (pre-1.7) and context (1.7) at the same time…

Kind of drawing blanks right now.

[crast]

@puellanivis The simple solution: Have people keep using golang.org/x/net/context - it already has provisions where it will use all the underlying implementations from go 1.7 context.Context if running in go 1.7.

You can pass a x/net/context.Context to a function expecting a context.Context because both of the interfaces have equivalent method sets. The only problem here is in satisfying the function signature from generated servers. What it means is go 1.7 users using GRPC will still need golang.org/x/net but this isn't really a huge deal.

You can compose contexts using e.g. WithTimeout WithCancel from both packages and it will do the right thing.

[crast]

^ fwiw, I've already tested the above on go 1.7beta1, and it works, and the advantage is the same code works on go 1.5, 1.6. 1.7

[puellanivis]

The problem is not the problem with being able to pass a context.Context into a function that takes golang.org/x/net/context.Context, it's that you can't use a Server with a receiver method func (s *Server) gRPCCall(ctx context.Context, in *pb.RequestProto) (out *pb.ReplyProto, error) into a function that wants an interface with a receiver method of gRPCCall(ctx golang.org/x/net/context.Context, in *pb.RequestProto) (out *pb.ReplyProto, error)

They don't match, because of Go's strong typing. Therefore, you need a mishmash of "golang.org/x/net/context" and "context" in different situations, where you use the x/net/context when you need to have a server match the method signature for the interface in gRPC, while you can use context elsewhere.

Yes, a work around is still “just use golang.org/x/net/context forever", but the whole reason for putting context into the standard library is that it's no longer experimental anymore and isn't confined semantically into the "net/" packages anymore.

[puellanivis]

What it means is go 1.7 users using GRPC will still need golang.org/x/net but this isn't really a huge deal.

Except now, because I have things that expect a context.Context receiver signature in the interface, and the gRPC one that expects a golang.org/x/net/context receiver signature in the interface.

So, now, I have to include two context packages, rename one of them, and one of them is obsoleted by the other. And then I have to remember which of the context packages I renamed, and remember if and when I didn't need to rename it because I'm only using one context type.

I made that stepping stone the same day this bug was filed, but it is not good programming.

When 1.7 releases, use of golang.org/x/net/context should be considered deprecated, and likely to disappear in 1.8, because that's how taking things out of the experimental tree typically works.

[crast]

I made that stepping stone the same day this bug was filed, but it is not good programming.

Conversely, a package which breaks version compatibility in weird ways for the sake of reducing package count isn't good package maintenance.

Yes, a work around is still “just use golang.org/x/net/context forever", but the whole reason for putting context into the standard library is that it's no longer experimental anymore and isn't confined semantically into the "net/" packages anymore.

"forever" is kind of over-blown, given how fast the Go ecosystem moves. If the trend shown in the last set of security fixes this spring hold, where the crypto vulnerability was only fixed for 1.5 and 1.6 (1.5.4 and 1.6.1) then the currently supported versions of go is the last 2 minor versions. At the current release rate of one every 6 months, this means that by February 2017, the only Go versions getting security updates will be 1.7 and 1.8. Anyone still on <=1.6 at that point who wants to run a server will move up.

I think it's completely sensible to keep using x/net/context until approx. February 2017, to facilitate the transition

[puellanivis]

Conversely, a package which breaks version compatibility in weird ways for the sake of reducing package count isn't good package maintenance.

Which is why I don't. My package github.com/puellanivis/protobuf/proto for instance doesn't break version compatibility. It uses "context" when go1.7 build tag is defined, and uses "golang.org/x/net/context" when go1.6 is defined.

I would expect my eventual solution for gRPC will do similar.

At the current release rate of one every 6 months, this means that by February 2017, the only Go versions getting security updates will be 1.7 and 1.8. Anyone still on <=1.6 at that point who wants to run a server will move up.

And if we fix it now, when people move from 1.6 to 1.7, they'll just replace "golang.org/x/net/context" with "context" and everything will continue to work. This would best be complete while 1.7 is the most recent release. Then at 1.8, drop support for 1.6.

I think it's completely sensible to keep using x/net/context until approx. February 2017, to facilitate the transition

But why wait until the last day? Why procrastinate? This is like the Y2K bug. We know it's going to happen, so why not fix it NOW, rather than in a rush before it's required?

I understand that you believe it to be sensible to keep using golang.org/x/net/context. However, not everyone need agree with you. I can work on this while other people work on other things, and eventually, integrate my patches (in a way that will not break version compatibility), and then people can switch over to using just "context".

This is a snowdrift, and I'm plowing it. One shouldn't be looking to stop me from plowing it by saying that we don't have to get to work until 17:02, and it's only 16:06, so like, “We have like an hour dude, we don't need to do it now.” I don't care, I'm clearing the snowdrift now. I can take my time and make sure it's done right the first time, rather than adhoc because last second.

[puellanivis]

BUT… I don't actually have to change any of the grpc-go files that are not defining types… which saves a lot of effort and/or duplication of code.