Change import httplex to httpguts.

[h8liu]

This fixes go get.

Breakage caused by: golang/net@cbb82b5

[onlyjob]

That seems to break compilation with Go 1.10... Is this intentional?

[harshavardhana]

That seems to break compilation with Go 1.10... Is this intentional?

Yes why would it break? . I am using go 1.10.2. you need to fetch the new dependencies Go upstream broke the dependency by moving the package so we have to do it.

[onlyjob]

I'm getting src/github.com/minio/minio-go/api-put-object.go:31:2: cannot find package "golang.org/x/net/http/httpguts". golang.org/x/net is locked to 1.10, same version as compiler...

[harshavardhana]

go get golang.org/x/net/http/httpguts/... - should work fine.

[onlyjob]

That's not that easy... We need to build against reusable package golang-golang-x-net-dev in Debian and x/net (as a standard library) appears to be in sync with compiler version. Blatantly updating x/net may break many packages...

Never mind though, for now I've uploaded minio-go 6.0.1. Thanks.

[harshavardhana]

That's not that easy... We need to build against reusable package golang-golang-x-net-dev in Debian and x/net (as a standard library) appears to be in sync with compiler version. Blatantly updating x/net may break many packages...

Never mind though, for now I've uploaded minio-go 6.0.1. Thanks.

Well I think that style of packaging never really works in Go world, we have to update anyways since our users who use go get will be broken. Since most of our users simply use go get this is not a problem. Sticking to an older release is correct in your situation.

[onlyjob]

Fair enough. However IMHO golang vendoring mess is an abomination of 20+ years of best practice in software engineering. :) For example, no tests are run for any of (vendored) dependency libraries on build. In Debian we are trying to do it right by building reproducibly in offline build environment, running tests for all libraries on all supported architectures, etc. Use "stable", semantically versioned libraries whenever possible (versus random commits, as often vendored by many Goland developers), etc.

[harshavardhana]

Fair enough. However IMHO golang vendoring mess is an abomination of 20+ years of best practice in software engineering. :) For example, no tests are run for any of (vendored) dependency libraries on build. In Debian we are trying to do it right by building reproducibly in offline build environment, running tests for all libraries on all supported architectures, etc. Use "stable", semantically versioned libraries whenever possible (versus random commits, as often vendored by many Goland developers), etc.

Perhaps, but from our end we can't do much. Perhaps Debian can work with Go developers to fix this problem. Perhaps the new vgo initiative is a good progress in that direction?

[onlyjob]

Of course, of course. :)
I hope that vgo will improve situation...