3 ms·

I tried doing the modules tutorial a while back but had difficulty with the directory structure. At some point I think the "recommended" directory structure be

• mseepgood 5y ago
  Modules don't require any particular directory structure, just a go.mod at the root of your project.
  • hamburglar 5y ago
    That’s “a particular directory structure” that conflicts with many already-existing projects. What if I have a mostly-java project that has a couple bits of go code buried in it that I want to use as modules? Break it up into multiple repos for no good reason? No single tool should be acting like it owns the root directory of my repo.
    • mseepgood 5y ago
      The root of the Go project with the go.mod file doesn't have to be the root of the repository.
      • hamburglar 5y ago
        Doesn’t it? Is this new?
        • mseepgood 5y ago
          As far as I know this was always possible since modules were introduced. You just have to prefix the version tags for Go with the subdirectory in the repo: "my/sub/directory/vX.Y.Z"
          • hamburglar 5y ago
            I swear it didn’t always work this way, but I’m happy to be wrong.
            • echlebek 5y ago
              The only difference is that you are expected to tag differently. For instance if you had reporoot/hello/go.mod, you would create tags like hello/v1.2.3
        • deleted 5y ago
          [deleted]
      • chrsig 5y ago
        For that matter, you can have multiple modules in a repository.
    • zemo 5y ago
      I hate this pattern too but there's not "no good reason", there's a specific reason why it's like this, and it's a conscious design choice. When you call `go get somedomain.com/whatever/thing`, what it does is makes an HTTP request to that URL, then looks for a `<meta>` tag on the page telling it where to download the module. Check out the source of any Go project on github and you'll find the relevant `<meta name=go-import ...>` tag. Here's the meta tag for the gorilla router, a common http routing library: <meta name="go-import" content="github.com/gorilla/mux git https://github.com/gorilla/mux.git"> The tool is designed so that you can serve modules directly from version control repositories, because the goals were to avoid having any central authority on modules. It turns out this is a huge win in terms of making it dramatically easy to empower people to release modules, AND a huge win for decentralization: if you can host a git repository, the git repository is the module source, and that's the entire system. Just use Go as normal and make a public github repo and it's automatically importable through `go get`. No central registry required. It's a tradeoff. In making it "one module per repo", it dramatically lowered the barrier to entry for producing modules that other people could adopt right away, but it requires that you have one module per repo, because the versioning scheme is based on tags having semver version strings in them. Could they have made it something like "a tag can specify a directory and a version"? Hahha, yeahhhhhhhhhhh probably. But they didn't. In any case, you can also serve modules out of a go module proxy directly, but then you have to set that up yourself. That would free you of the "one module per repo" thing, but now you don't get "a repo is automatically accessible as a Go module". You'd have to implement the Go module proxy protocol yourself. I'm ... doing this now in my spare time but it's not really ready to share yet. The protocol is actually super easy to implement. It's described here: https://go.dev/ref/mod#goproxy-protocol https://go.dev/ref/mod#goproxy-protocol
      • uncomputation 5y ago
        The whole meta tag thing seems to break the “principle of least surprise,” as I had no idea that was how go get worked.