This sounds like it would warrant a howto go modules blog post. Thank you for sharing your experience.
michael...@gmail.com schrieb am Samstag, 10. April 2021 um 02:20:54 UTC+2: > FWIW, I completely agree with the sentiment that confusing documentation > has created pain and unnecessary difficulty for solo developers. I try to > keep in mind that Go was developed for use by large teams working on > million line programs and that I'm lucky to be able to piggyback on the > efforts of top-notch talent. > > That being said, here is a recipe that seems to work -- for my purposes at > least. It's really just a restatement of what others have said in this and > related threads: > > 1. Create a directory that will hold your local projects. I think it best > not to use ~/go/src. My directory is ~/localgo, I'll use that name in > in what follows, though there's nothing special about it. > 2. Undefine GOPATH, e.g. unset GOPATH > 3. Initialize a module named for the directory, i.e. cd ~/localgo; go > mod init localgo > 4. Move your package and cmd project underneath ~/localgo. > 5. When importing local package named "somepkg" use import localgo/somepkg > 6. If a package in your local directory is something you've published, you > have three choices when importing it: > > - Import it from your published repository, > - Import from your published repository and use "replace" to force the > import to use the localgo copy, > - Import directly from localgo (as in item 5). > > To make this a little more concrete here's a portion of my localgo tree > with two packages and two command projects. Notice that mypkg and myprog > do not have go.mod files yet myprog is able to import mypkg and build > without error. Package tbchrom, on the other hand, is already > (privately) published and versioned on GitHub. It's still under > development. Having it cloned under localgo allows me to reference it > from command tbflash which is not yet published. I'm using the replace > statement in tbflash's go.mod file, i.e., replace > github.com/Michael-F-Ellis/tbchrom v1.0.0 => /Users/mellis/localgo/tbchrom > > localgo > ├── go.mod > ├── mypkg > │ └── pkg.go > ├── myprog > │ └── main.go > ├── tbchrom > │ ├── .git > │ ├── .gitignore > │ ├── .vscode > │ ├── go.mod > │ ├── go.sum > │ ├── parser.go > │ ├── parser_test.go > │ ├── rhythm.go > │ ├── rhythm_test.go > │ ├── smf.go > │ └── smf_test.go > └── tbflash > ├── go.mod > ├── go.sum > ├── main.go > ├── main_test.go > └── tbflash.json > > I like this solution because it's consistent and flexible. It's consistent > in that all the go toolchain commands, vet, build, ... etc., work the same > regardless of whether a package or command if version controlled or has a > go.mod file. It's flexible, in large part, because it's consistent. I can > start a project with bare Go code and add module support and version > control as needed. > > Hope someone finds it useful. If you know of any awful pitfalls, please > let me know. > > On Friday, April 9, 2021 at 5:34:37 PM UTC-4 ohir wrote: > >> Dnia 2021-04-07, o godz. 14:31:07 >> Slawomir Pryczek <slawe...@gmail.com> napisał(a): >> >> > Anyone has an idea for a reasonable solution which will allow easy >> > refactoring and code organization in packages, in this new model? >> >> Idea is here: https://github.com/golang/go/issues/44347 >> >> Whether is it reasonable or not — objectively — I can not tell as I am an >> author. >> Though I'd like to see other's opinion whether proposed solution would >> work for them. >> >> TC. >> >> -- >> Wojciech S. Czarnecki >> << ^oo^ >> OHIR-RIPE >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4df0c9e7-a094-492e-843b-7ef7472db599n%40googlegroups.com.
