Outstanding open issues / PRs in satori/go.uuid

[acln0]

We should take a look at the open issues and pending PRs in https://github.com/satori/go.uuid and see if which ones would be worth tackling / adopting.

satori/go.uuid#44 was brought up, which I think is a good start.

Please comment with other issues or PRs if you think they'd be worth doing.

[theckman]

I pinged PR-44 to ask if they'd be willing to re-open the PR here.

[theckman]

I think we might be nearing the ability to close this ticket. We should give a final 👍/👎on the feature requests that are outstanding.

Here's a quick classification of their PRs:

Desired / In-Progress

• Add json (un)marshalling methods on NullUUID satori/go.uuid#44 (Add JSON (Un)marshaling methods on NullUUID type #38)
• Add Time() and Nanos() methods satori/go.uuid#50 (Add Time() and Nanos() methods #31)

Fixed by this package:

• Add missing return to README satori/go.uuid#72
• Fix potential non-random UUIDs satori/go.uuid#75
• Add deprecation notice to README and package docs satori/go.uuid#85

Obsoleted by this package

• Revert breaking changes and add new GenV* interfaces satori/go.uuid#68 (in that we've released a major version)

Unsure if we want to support this:

• Adding methods to allow to get UUIDs with random MAC address satori/go.uuid#63 (Request: Allow to get UUIDs with random MAC address satori/go.uuid#64)

Issues

Feature requests:

• Allow to get UUIDs with random MAC address satori/go.uuid#64 (PR: Adding methods to allow to get UUIDs with random MAC address satori/go.uuid#63)
• Origin validation satori/go.uuid#40

Deprecation requests:

• Add deprecation notice in favor of github.com/gofrs/uuid and archive this repo satori/go.uuid#84
• Consider archiving this repo satori/go.uuid#83

Fixed by this package:

• Newer release satori/go.uuid#82
• fork with tag v2.0.0, state = current master satori/go.uuid#80
• dep fails because of the old versioning and it breaks the programs completely satori/go.uuid#77
• New Version satori/go.uuid#76
• NewV4: non-random uuid satori/go.uuid#73
• multiple-value uuid.NewV4() in single-value context satori/go.uuid#71
• not enough arguments in call to uuid.Must satori/go.uuid#70
• undefined: uuid.Must satori/go.uuid#69
• Breaking API Change satori/go.uuid#66

Random questions (should probably be closed):

• Is uuid.NewV4() thread safe? satori/go.uuid#81
• uuid: cannot convert uuid.UUID to UUID satori/go.uuid#79
• Any potential problems for changing Size from 16 to 8 satori/go.uuid#78
• [Question] It doesn't support to transform between Big-endian and Little-endian in net work satori/go.uuid#74
• Can't scan into *uuid.UUID satori/go.uuid#47
• uuid.Value []byte vs string satori/go.uuid#38

[theckman]

Do we want to support the ability to generate random MAC addresses for V1 IDs as an option? There an issue (64) and PR open (63) on the other repo to support this functionality, and figured I'd poll here before asking.

[niaow]

I think it makes more sense to allow the user to specify a MAC than to generate a random MAC.

[zerkms]

There is a hwAddrFunc field available: if we expose it via another constructor - a user may provide a function that returns a random mac every time.

[theckman]

We're likely going to need to expose the generator implementation, so that it can be done that way. I think this could be done in a minor release if we wanted, as we'd be adding-on.

[theckman]

@zerkms I took a swing based on your comment above: #42

[theckman]

I'm going to close this issue out now, since I think we're engaged on the things we should be engaged on. We can follow those up in the individual PRs/issues.

Thank you for raising this, and for the input that was given by everyone.