Support Go Modules #1
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
|
Thanks, I need to familiarize myself with Go modules first, but I'd be happy to support that in this library. As for the organization, the |
Contributor
Author
|
Sure thing; let me know if there's any way I can help or anything I can clarify WRT modules. |
Member
|
Okay, I think I got the basics of modules now. Merging now, and then I'll make a v1.0.1 tag. Thanks again @SamWhited! |
Member
|
Actually, went with v1.1.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
Please consider supporting Go Modules, the new packaging standard that will be adopted fully in Go 1.12. Experimental support is in Go 1.11 and the new module paths are supported in Go 1.9.7+ and Go 1.10.3+ in a read-only manner for backwards compatibility with all supported versions of Go (although the import path doesn't change with this library, so it doesn't matter much here).
Because this library has no external dependencies and is still below version 2, the
go.modfile is fairly simple. The only other thing that would need to be done is to create a semver compatible tag after this patch is merged (eg. v1.0.1) to allow other things to pin to that version without having to use the special commit-based version string.Also: I notice that the various write.as packages are a bit inconsistent in how and where they live. Eg.
go-writeasuses a self-hosted gopkg.in and has an import path at code.write.as, this package has a GitHub import, and still others use a code.as import. Is there something you plan to standardize on? Modules make the gopkg.in style imports unnecessary (it might even be broken, I'm not sure), but otherwise it's probably best to decide what the final import path will be before setting it in a module (EDIT: if you prefer to have things on a domain that you control and is distinct from the source repo's domain, there's also the option of using a meta tag whichgo getunderstands to redirect from whatever domain you choose).Thank you for your consideration.