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/34e47688-3644-4005-a226-262fc2c480bfn%40googlegroups.com.
