Skip to content
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

Update UUID vendor #51

Merged
merged 2 commits into from
Dec 23, 2018
Merged

Update UUID vendor #51

merged 2 commits into from
Dec 23, 2018

Conversation

whilei
Copy link
Contributor

@whilei whilei commented Dec 22, 2018

It appears github.com/satori/go.uuid is functionally deprecated,
and has been superceded by github.com/gofrs/uuid.

This came to my attention because of un-tagged changes to
satori/go.uuid that changed the signature of uuid.NewV4()
from a single return val to two, resulting in:

$ go get github.com/Jeffail/leaps/cmd/...
warning: ignoring symlink /Users/ia/go/src/github.com/Jeffail/leaps/cmd/leaps/www
warning: ignoring symlink /Users/ia/go/src/github.com/Jeffail/leaps/cmd/leaps/www
# github.com/Jeffail/leaps/lib/util
go/src/github.com/Jeffail/leaps/lib/util/uuid_gen.go:51:19: multiple-value uuid.NewV4() in single-value context

Of course running 'dep ensure' fixed this issue, but
it seems like this project should use the 'longer fork'
of this dependency in any case.

It appears github.com/satori/go.uuid is functionally deprecated,
and has been superceded by github.com/gofrs/uuid.

- satori/go.uuid#84
- satori/go.uuid#90

This came to my attention because of un-tagged changes to
satori/go.uuid that changed the signature of uuid.NewV4()
from a single return val to two, resulting in:

$ go get github.com/Jeffail/leaps/cmd/...
warning: ignoring symlink /Users/ia/go/src/github.com/Jeffail/leaps/cmd/leaps/www
warning: ignoring symlink /Users/ia/go/src/github.com/Jeffail/leaps/cmd/leaps/www
# github.com/Jeffail/leaps/lib/util
go/src/github.com/Jeffail/leaps/lib/util/uuid_gen.go:51:19: multiple-value uuid.NewV4() in single-value context

Of course running 'dep ensure' fixed this issue, but
it seems like this project should use the 'longer fork'
of this dependency in any case.

This change does NOT address the 'what to do with the
error value' question; it just ignores the possible error.
Intended as a way to 'handle the error without handling the error'.
@Jeffail Jeffail merged commit b534e67 into Jeffail:master Dec 23, 2018
@Jeffail
Copy link
Owner

Jeffail commented Dec 23, 2018

Thanks @whilei!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants