Azure-sdk-for-go: address breaking change in satori/go.uuid

[joshgav]

Several issues have been opened: https://github.com/Azure/azure-sdk-for-go/issues/945, https://github.com/Azure/azure-sdk-for-go/issues/940, https://github.com/Azure/azure-sdk-for-go/pull/946.

Also: https://github.com/satori/go.uuid/issues/66

Let's get a fix in perhaps starting with #946 and release a new minor. Thanks!

@carolynvs do you have suggestions on how we can best shield users of our library from changes in transitive dependencies? Is dep's recommended practice for users to explicitly declare the dependency and version in their own Gopkg.toml file? Thank you!

[joshgav]

If you're looking for a workaround, see https://github.com/satori/go.uuid/issues/66#issuecomment-355382630.

[carolynvs]

@joshgav I thought go.uuid was a _direct_ dependency of the sdk, so a constraint should have worked. Testing now!

[carolynvs]

@joshgav It appears to me that anyone who is using dep to manage their dependencies should already be shielded from the breaking change in go.uuid. The sdk's Gopkg.toml specifies 1.1.0 for go.uuid. When someone uses dep on their project, and pulls in the sdk as a dependency, dep will enforce that constraint.

I looked at some of the other bugs and they appear to all be from non-dep consumers of the sdk.

Let me know if you've seen reports of anyone using dep to vendor the sdk who is having trouble!

[carolynvs]

To be clear, dep isn't built into the go toolchain yet. So even if a library has dep configuration files, when the consuming project doesn't use dep, running things like go get or go build won't pick up and use dep's configuration. The end-user needs to use dep as well.

[joshgav]

awesome, thanks @carolynvs!

[ritazh]

running things like go get or go build won't pick up and use dep's configuration

yea completely agree with @carolynvs we just need to update the readme

[carolynvs]

Let me know if I can help clear up any other confusion about how dep works. I see #948 is doing some work that sounds like its to avoid certain behaviors in dep, but I'm not clear on what?

[vladbarosan]

@carolynvs that change you are mentioning is to help people using go get. The change was the only place where we were actually using the function with the breaking change so we switchted to another package for getting the UUID there so pretty much anyone using go get won't have problems with satori's breaking change with the go sdk.

[carolynvs]

Gotcha, thanks! 👍