create go.mod and go.sum

[lizthegrey]

This ensures that users can import it as a /v3 module without needing the +incompatible go mod syntax.

[cameracker]

This will probably wait until a breaking change is made to the library, such as the removal of uuidv2. #61

[theckman]

Hi Liz,

Thank you for raising this.

We currently have no interest in adopting Go Modules, as it would break people who use dep, glide, or any package manager that doesn't support SIV. I wish the Go Authors wouldn't have put us in this unfortunate position. Please see this comment for more context:

• module support #74 (comment)

Edit: this may change in the future, but right now we are holding steady with that plan.

Edit2: selfishly, I'd like to see them resolve the sociotechnical issues with the Modules system, before I'd feel comfortable adding Modules and forcing people to them.

[PaluMacil]

I'm not sure if you have a specific threshold, @theckman for making a major release and considering mod to be the official choice. In the 2019 go survey, they said:

Almost everyone in the Go ecosystem is now using modules, but some confusion around package management remains.

This meant 89% said they used go mod, and modules were first available in 1.11, so now that we are on 1.14. And finally, if someone has older ways of doing this, they have an easy path away from things like dep and Glide:

go mod init automatically translates the required information from dep, glide, govendor, godep, and 5 other pre-existing dependency managers into a go.mod file that produces the equivalent build.

Personally I thought dep was awful and still feel frustrated when I think about the issues I tried to raise in that community, but I understand that some people didn't like all the choices made by go mod either, and there are a couple things I would have done differently. At this point, I'm far more concerned about seeing the community be able to see projects adopting the official way of doing things. When I see a library not using go.mod now, I always need to dig a little further to see if it's a dead project, and I appreciate your library a lot and don't want people to skip over it because they assume it isn't being maintained.

The wiki page for go mod encourages everyone to use go mod now:

In Go 1.14, module support is considered ready for production use, and all users are encouraged to migrate to modules from other dependency management systems. If you are unable to migrate due to a problem in the Go toolchain, please ensure that the problem has an open issue filed. (If the issue is not on the Go1.15 milestone, please comment on why it prevents you from migrating so it can be prioritized appropriately). You can also provide an experience report for more detailed feedback.

[theckman]

Thank you for reaching out. If there's something that's preventing Modules users from working with our package we're happy to try and address that. I hope our responsiveness here helps quell any maintenance concerns. 🙂

I'm personally still preferring the conservative approach because of SIV. If that wasn't an issue here we'd have Modules support awhile back.

[stellirin]

I'd also welcome adding modules here, perhaps the release of Go v1.16 could be a reasonable enough milestone, when modules will have been GA for three major releases?

As hinted at above, I actually did skip over this project in favour of github.com/google/uuid, simply because of module support and a few more recent commits in the Git history.

But I just now had a conflict with an imported package that uses this uuid package. It didn't feel right to have two uuid implementations in one project so I ran some benchmarks for my use cases (mostly uuid.Random() vs uuid.NewV4()). I found that this repo is consistently around 15% quicker than the Google repo, so I decided to give this project another look.

Overall, a pretty trivial reason actually, but I doubt I'm the only 'newcomer' to Go that has similar opinions about module-less projects.

[markfarnan]

Please support go modules. The go world has moved on and module support is basically required.

[cameracker]

Hey @markfarnan , I'm not necessarily opposed to having modules support and generally a proponent of going with the direction of the ecosystem at large, but as far as I can tell this library works perfectly fine without it and users are able to incorporate it into their applications without an issue. Also, SIV is basically useless for this library because the upgrade path through majors is very small due to the size of the package, and I can't imagine a good use case for having two major versions of this library in play. I'd argue that it's probably good to have it in most libraries but this one is so lightweight and inobtrusive that modules doesn't really add a lot to it over the basic git tagging.

Could you explain why you think module support is "basically required" for this package? The reason it's not already supported is because it created a huge amount of pain last time we tried to introduce it and there hasn't really been a great opportunity to try again.

Thanks!

[theckman]

We could just archive the project and let folks use google/uuid. If they've already chosen that project over ours, do we have an incentive to invest our time to add Modules support for a questionable gain?

As far as I know there isn't a need for modules to be here.

[cameracker]

@theckman

I don't know, this is a pretty good testimonial on this library being great!

I found that this repo is consistently around 15% quicker than the Google repo, so I decided to give this project another look.

[theckman]

If there is a way for us to release without requiring a SIV import I am down to adopt Modules, otherwise I'm still aligned with the chi project and would like to pass.

[theckman]

It looks like someone raised a PR to introduce modules as v420, not sure if there is any feedback from those who raised this issue on that and whether it would fit their needs / they have any concerns.

[cameracker]

The tentative decision is to release tip of master on a git tag release, and then merge in a few prs as a breaking major on another git tag release.

I will investigate the impact releasing a breaking major will have on module users. We know that it will be supported in other package management systems that may still be in play. The expected impact is very little, it'll at worst retain the incompatible label that is already there.

[PaluMacil]

We could just archive the project and let folks use google/uuid. If they've already chosen that project over ours, do we have an incentive to invest our time to add Modules support for a questionable gain?

I'm a thankful user of your project. I commented last May, and indeed your responsiveness, library performance, and the good API are why I use this. I would still gain not having to look at all the imports in every source file each time I update to make sure you still don't have anything external. If you had anything external referenced, there would be unbounded variability from those dependencies and their dependencies, etc.

[cameracker]

I'm going to close this issue. The discussion and feedback is appreciated, but I think given the amount of pain we had trying to introduce go modules last time, versus what the library stands to gain by introducing it doesn't have the right tradeoffs at this time. Ultimately, the library works fine with applications or other libraries that are using go modules, and fear of the "incompatible" decorator is probably best met with better training on what that means.

Please feel free to keep responding to this ticket if you have additional feedback or observations.

As a side note, any PR that introduces go module support will need to prove that the library is installable correctly in various contexts and different version targets.

[codestation]

Can this be reconsidered? Most of the Go community already moved towards Go modules and the other popular package managers are either deprecated or abandoned.

Glide stopped development almost two years ago and even their website is down.
Dep was archived 8 months ago and was deprecated in favor of Go modules.

The point of #61 is less relevant nowadays as new projects are using Go modules as there isn't a viable alternative anymore.

[theckman]

@codestation is there some non-cosmetic issue that us not having go.mod file causes?

As of now, introducing a go.mod is going to be a massively breaking change for all consumers because we need to change our import path. If a lack of go.mod causes no issues, then I'm inclined to continue delaying the adoption since it causes no work for consumers.

If I could somehow roll this project back to a v0 release so that it would be easy to add a go.mod file I would, but I can't. If this Go proposal were accepted I'd be 100% on board: golang/go#44550.

[cameracker]

My 2cents:

Now would be a relatively safe time to go to go modules because we will be at a sweet spot where the bare import and the v4 import would both basically resolve to our most recent breaking change (removal of UUID V2). This library is effectively "done" and there are very few changes going though.

That said, I'm still of the opinion that a PR that introduces modules needs to show exercise of various import scenarios go where expected. Personally, I'm pessimistic that we will have the inclusion of module support go as expected.

[coder543]

[source]

It seems worth mentioning that the second most commonly used package manager fell in usage by over 60% from 16% of respondents to 6% of respondents. Go Modules went from 89% to 96%.

If this decline holds up for another year, usage of alternative package managers is likely to be negligible by the time the survey results come out next year.

Reviewing the state of alternative package managers:

• Dep itself was archived and self-deprecated over a year ago, pointing people at Go Modules.
• Govendor's repo has implored users to stop using it for the past year and a half.
• Godep has been pointing users to use other tools for the over 3.5 years since it last received a commit.
• Glide has been recommending Go Modules for over 2 years now.

Given that this repo appears to have no external dependencies, this is one of the few repos that truly can say go.mod doesn't make any substantial difference... but at a certain point, alignment with the rest of the community is worth something, and I'm not sure it will be worth more for much longer to support legacy tools whose authors have long discouraged their use, and whose userbases have been rapidly dwindling. But, maybe it is still worth it for now... it would just be nice to define a threshold. Is the threshold really "while a single person still uses something other than Go Modules"? Does this repo still support the initial Go 1.0 release? I would assume not... if it does, that's certainly impressive.

Just my two cents. ¯\_(ツ)_/¯

I would obviously like this repo to adopt Go Modules for consistency with the rest of my dependencies, and I readily admit that this is not super consequential. But since this discussion seems to be focused on the merits of supporting still-used alternative package managers, I figured I would highlight some new data that shows how rapidly such usage continues to decline.

[theckman]

@coder543 the blocker right now is that we'd need to release v5 and force consumers to append the major version onto the repo name, and nothing to do with alternative package managers. We want to avoid having to put the major version on the name.

This will probably require that we fork the project and then become a v0-only project.