appengine

[go-chi]

appengine

[pkieltyka]

Perhaps you should look elsewhere if you're so unhappy?

[pkieltyka]

this would have been solved by the 1.8 alias feature, which may come in 1.9.

I have thought about this, but this problem you speak of, isn't up to chi. Chi uses standard net/http which uses "context", and so we depend on the same "context" thats now part of the http.Request object.

[twiggg]

:) this was not a comment about chi router, but about the fact that community version of golang (by google) and appengine version of the runtime (by google too ...) are tricky to make work together

[pkieltyka]

well, let me know if you come up with something.. I agree this isn't ideal. I'm pretty sure if I made a branch of chi that used "golang.org/x/net/context" it wouldn't help anyways because of net/http's use of "context".

[twiggg]

not sure neither ... wctx router seem to work on appengine but I wanted to stick with chi

[pkieltyka]

well you can use https://github.com/pressly/chi/tree/v1 which is almost identical and is compatible with "golang.org/x/net/context"

[VojtechVitek]

googleapis/google-cloud-go#312

[twiggg]

yes thank you Vojtech I have read that they are aware of the mess this fragmentation causes ... but still have not found my way around (appart from not using libraries that import /context and not /x/net/context ... ) net/http.Request.Context() is using a context.Context so even change all imports of /context to /x/net/context in chi and render does not work