-
Notifications
You must be signed in to change notification settings - Fork 848
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
address breaking change in satori/go.uuid #947
Comments
If you're looking for a workaround, see satori/go.uuid#66 (comment). |
@joshgav I thought go.uuid was a direct dependency of the sdk, so a constraint should have worked. Testing now! |
@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 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! |
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 |
awesome, thanks @carolynvs! |
yea completely agree with @carolynvs we just need to update the readme |
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? |
@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. |
Gotcha, thanks! 👍 |
* Moving UUID generation to github.com/marstr/guid Fixes #947 * Removing comment block, and instead copying here: Basically, the issue is our code needs to be able to operate regardless of whether people have vendored in code on either side of Satori's inadvertant breaking changes. That leaves us two options: 1. Use reflection to try to invoke hichever method is available to us in Satori's package. 2. Take a dependency on an alternate library for the sake of generation. I've opted for strategy two, because it is easier to validate. Once Satori has resolved this, it would not be inappropriate to revert this code change. * Adding changelog note. * Update version info. * Tweak changelog. * Fix travis and delete glide files.
Several issues have been opened: #945, #940, #946.
Also: satori/go.uuid#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!
The text was updated successfully, but these errors were encountered: