On Monday, 21 November 2022 at 04:11:26 UTC pat2...@gmail.com wrote: > > Incidentally, there is no need to have github.com in the directory path >> on your local filesystem. You could just use >> ~/projects/cmd >> > > Doesn't this contradict putting the github path in the name for easy > automatic use? > Or am I confusing two issues? > > You are confusing two issues, although this probably comes from your experience with go before GOMODULES, where you did have an automatically-created hierarchy under $GOPATH/src. I came to go just as the transition was taking place.
There are two separate concepts now: (1) The *name* of your module. This conventionally looks like github.com/pfarrell51/cmd to allow automatic fetching from github (but doesn't have to). (2) The *directory* on your local filesystem where your code lives. This can be anywhere and does not have to look anything like your module name. This is because the "go.mod" file provides the binding between the module name and filesystem location. - if the current directory contains go.mod, then go.mod names the package in this directory - if the current directory doesn't contain go.mod, then go walks up the filesystem to find one. Then the name of the package in the current directory is the name of the module in go.mod, concatenated with the subdirectory path needed to get from go.mod's directory to this one. That is: if ~/projects/misc contains a go.mod with name example.com/test, then ~/project/misc/foo has name example.com/test/foo implicitly (as long as it doesn't have its own go.mod file). > >> Note that import "github.com/pfarrell51/cmd" doesn't mean "fetch this >> code from github". It just refers to the module's name. By walking up the >> parent directories and finding go.mod, Go realises that the named module >> you are referring to is already on your filesystem as part of your project, >> and uses that directly. This is why it works to use random module names >> like example.com/test >> > > I'm not following this, I thought that was exactly why I put in the " > github.com/pfarrell51/< <http://github.com/pfarrell51/cmd>modulename>" > in the source directory structure, and therefor in the github > https://github.com/pfarrell51/gows repository > so if someone wanted to use my PID code or my quaternion code, it would be > easy and automatic > > For somebody on a remote system, yes. On your own system, let's say you have the following tree: ~/projects/cmd # contains go.mod with name github.com/pfarrell51/cmd ~/projects/cmd/foo ~/projects/cmd/bar In the "foo" subdirectory, there is some code which says import "github.com/pfarrell51/cmd/bar" When you compile this code, go finds the go.mod file *in your own filesystem* (in the enclosing directory). It knows that ~/projects/cmd is github.com/pfarrell51/cmd. Therefore, github.com/pfarrell51/cmd/bar can be found at ~/projects/cmd/bar (as long as that subdirectory doesn't have its own go.mod file). Hence it doesn't go off to github to fetch github.com/pfarrell51/cmd/bar - which would be very confusing, since this is a package inside the module you're actively developing, and may not even have been published to github at all yet. It uses the local copy. Now suppose you've finished it, and you push it to github. A different person writes some code with import "github.com/pfarrell51/cmd/bar" For their own code, they need to have their own go.mod file with their own module name. The system can see easily that the module they're writing is not the same as the one they're importing. In this case, "go mod tidy" will go off to github and fetch the code, i.e. *your* code which *their* code depends on, and drop it into $GOMODCACHE I hope this makes a bit more sense! There is a nice series of blog articles starting at https://go.dev/blog/using-go-modules, although this assumes you know the old behaviour whereas really this is historic now. Regards, Brian. -- 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/61ce3bdd-1028-4dd1-8af5-b0552b498e7fn%40googlegroups.com.
