Thanks Ian ... so a couple of comments & clarifications (1) I see various other questions popping up in the list regarding go mod, go work, vendoring etc, and yes I certainly did review https://go.dev/blog/using-go-modules before posting my original question here. Point being, I think the documentation as currently presented is way too dense, leaves many degrees of freedom open, and thus it remains generally hard to quickly get to a basic understanding of the best practice of common usecases. I think the docs would greatly benefit from a list of those use cases that present a very brief outline of the commands that would be used to implement each, perhaps with some abridged contents of the go.mod's etc that result.
(2) With respect to my original question the answer for me was (as you mentioned) go get github.com/dustinxie/lockfree ... add the import to appropriate places in the source go mod tidy go mod vendor My original mistake was to run go mod tidy too early, such that it (silently) removed the lockfree package from go.mod because it did not appear anywhere in the source code. Yes, I acknowledge that go mod tidy is documented to clean up go.mod in that manner, but for whatever reason, I missed that, and it is silent in its cleanup. I was motivate to try go mod tidy because I noticed the the original go get dropped the module into go.mod as an indirect reference, and I wasn't sure that was correct I might suggest that the -v option be made the default, and that a -q "silent" option be provided instead? Where can I make that suggestion to the golang maintainers? (3) Now, imagine I wan't to make modifications to lockfree in such a way that those modifications can be submitted to my company's private repo, so that other developers can build the overall project successfully, and the modifications to lockfree can eventually be PR'ed to the original lockfree project. If I only fork lockfree to a new github repo, and I try to work with the go get/etc commands I will run into problems because in that new github repo, the lockfree/go.mod will contain the "wrong" reference for the module (it will point to the original github repo instead of the forked one). To overcome this issue, in the repo that wants to use the modified lockfree I create a directory to contain all my git submodules and in there I do: cd ~/my-go-project mkdir submodules cd submodules git submodule add --depth=1 g...@github.com:my-company/lockfree.git within that new clone I can then do the necessary feature additions to lockfree. Now, to resolve the issues with go's module system I then either: (3a) add a `replace github.com/dustinxie/lockfree => ./submodules/lockfree` in the project's go.mod OR (3b) yes, I verified this works ok even in the project dir that contains its go.mod: cd ~/my-go/project go work init got work add . go work add ./submodules/lockfree (4) Note: My understanding of the intent for `go mod vendor` is to snapshot the "external" sources used to build a project. Reasonably: I might expect the contents of the vendor'ed lockfree project to reflect what was actually being used to build the project in the context that go mod vendor executed in. Empirically: `go mod vendor` instead deposits a copy of lockfree from the original project source, not the source referenced in my go.work file. Should this difference be reported for consideration as a bug? If so, where should I do that? Thanks in advance for your responses. A. On Thursday, December 1, 2022 at 3:53:13 PM UTC-8 Ian Lance Taylor wrote: > On Thu, Dec 1, 2022 at 3:23 PM Andrew Athan <andr...@gmail.com> wrote: > > > > I am new to go devops (but not to the language). First, I must say, the > go module documentation is thorough but absolutely inscrutable for new > users. Googling for things like "golang add github module vendor" brings up > what appear to be either outdated or incorrect cookbooks. I've already > wasted 1 hour trying to figure out "the right way" to a module provided by > a github repo to an existing vendor'ed golang project. > > > > In short: HEEEELP! > > > > All I want to do is use `github.com/dustinxie/lockfree.git` > <http://github.com/dustinxie/lockfree.git> in the project, which *does* > commit the vendor directory to its git repo. I cannot seem to find any > semver defined in the lockfree project so I have no idea what to specify by > hand to go.mod, and there is a bewildering set possible commands to use ... > from `go get` to `go install` to `govendor` to `godep` (the latter appear > to be old news?) > > > > I would be eternally grateful for a few simple examples added to the > golang reference and/or tutorials for how to do this. > > First make sure that you have a go.mod file, typically by running "go > mod init my-package-path". Then run "go get > github.com/dustinxie/lockfree". The "go get" command will add the > package to your go.mod file, and you will be able to import it in your > Go files. > > A reasonable starting point is https://go.dev/blog/using-go-modules . > > If you want to do something else, please explain further what you are > looking for. Thanks. > > Ian > -- 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/fd53e0f8-48c4-4988-873e-c974bfc4f262n%40googlegroups.com.
