[LukeShu]

> What's the "current module", anyway? Where is that stored?

The article uses "current module" like you might use "current git repository"; it's the module containing the directory that you are currently `cd`ed to. Just as git identifies the repo by looking for `.git` in successive parent directories, go identifies the module by looking for `go.mod` in successive parent directories.

> > "go: downloading rsc.io/sampler v1.3.0"

> Downloading from where? Github? From what repository?

From the same place that non-module-aware `go get` downloads it. The only difference on the "remote side" of that from old `go get` is that it grabs the `v1.3.0` git tag, instead of git HEAD; if you don't specify a version it grabs the most recent `vSEMVER` git tag instead of git HEAD.

> > "the go command automatically looks up the module containing that package"

> Looks up where? GOPATH? The tree below the current file? The current directory?

Looks it up on the network, à la `go get`. Exceptions:

- The `replace` directive in your `go.mod` can manually override where it looks up a specific package.

- Telling Go `-mod=vendor` will have it look up all depended-upon modules in `vendor/`, rather than via the normal mechanisms; you can create the `vendor/` directory with `go mod vendor`.

It doesn't use the network every time; a module cache lives in `${GOPATH:-${HOME}/go}/pkg/mod/`; but you don't need to know that any more than you need to know that a build cache lives in `${GOCACHE:-${HOME}/.cache/go-build}`.

> There's some specific directory layout required, and you have to know what it is.

Not really, the only requirement is that you have a `go.mod` file that identifies a package name for the directory that it's in. So that if I have github.com/lukeshu/foo, it just needs a `go.mod` saying

    module github.com/lukeshu/foo

instead of having the requirement that it be checked out to `$GOPATH/src/github.com/lukeshu/foo`. Beyond having the `go.mod` file, there aren't really any structure requirements.

> This article needs to be more explicit about that.

Does it, though? It's a blog-post, not the "normal" documentation. The full docs are much more explicit and nitty-gritty than a high-level blog post.

[Manishearth]

As far as I can tell, rsc.io/sampler isn't a git repository, so it's not doing the same stuff `go get` does. If I try to clone it I just get hit by the HTTP redirect to the docs for rsc.io/sampler.

I may be missing something here (it's been quite a while since I did serious Go stuff so `go get` may have changed too)

> Does it, though? It's a blog-post, not the "normal" documentation. The full docs are much more explicit and nitty-gritty than a high-level blog post.

It's a bit weird to have a blog post about the new module system with nothing about how modules can be published, a pretty common task.

[LukeShu]

> As far as I can tell, rsc.io/sampler isn't a git repository, so it's not doing the same stuff `go get` does. If I try to clone it I just get hit by the HTTP redirect to the docs for rsc.io/sampler.

Why would you try to `git clone` it directly instead of trying to `go get` it?

    $ GO111MODULE=off go get -v rsc.io/sampler
    Fetching https://rsc.io/sampler?go-get=1
    Parsing meta tags from https://rsc.io/sampler?go-get=1 (status code 200)
    get "rsc.io/sampler": found meta tag get.metaImport{Prefix:"rsc.io/sampler", VCS:"git", RepoRoot:"https://github.com/rsc/sampler"} at https://rsc.io/sampler?go-get=1
    rsc.io/sampler (download)
    created GOPATH=/home/lukeshu/tmp-go; see 'go help gopath'
    Fetching https://golang.org/x/text/language?go-get=1
    Parsing meta tags from https://golang.org/x/text/language?go-get=1 (status code 200)
    get "golang.org/x/text/language": found meta tag get.metaImport{Prefix:"golang.org/x/text", VCS:"git", RepoRoot:"https://go.googlesource.com/text"} at https://golang.org/x/text/language?go-get=1
    get "golang.org/x/text/language": verifying non-authoritative meta tag
    Fetching https://golang.org/x/text?go-get=1
    Parsing meta tags from https://golang.org/x/text?go-get=1 (status code 200)
    golang.org/x/text (download)

It's been that way since at least 1.2 (I'm pretty sure since 1.0, but I haven't verified that memory). The process that `go get` follows is described by `go help importpath`.

The TL;DR is that it fetches `https://${pkgpath}?go-get=1`, and looks for `<meta name="go-import" content="...">` to tell it where to `git clone` from (with some hard-coded hacks for common websites that don't support that, like github.com).

> It's a bit weird to have a blog post about the new module system with nothing about how modules can be published, a pretty common task.

Because that hasn't changed. You still publish packages the same way you always have. The only difference in how you publish is that now "vSEMVER" git tags mean something.

[Manishearth]

Ah, I wasn't aware that the meta tag existed, everything about publishing crates seemed to point to using github (or a self-hosted repository of various supported VCSes)

Thanks.

The example using a less-commonly-known package distribution method is probably causing the confusion in Animats' original comment.