3 ms·
A go module is just a git repo (or svn/hg/etc repo, but almost always git). Versions are git tags or commits. Dependencies are specified in a go.mod file, spec
by TheDong 5y ago
A go module is just a git repo (or svn/hg/etc repo, but almost always git).
Versions are git tags or commits. Dependencies are specified in a go.mod file, specified here: https://golang.org/ref/mod#go-mod-file https://golang.org/ref/mod#go-mod-file
From the following go import path:
import "mywebsite.com/foo/bar/baz/v2/fizz"
We can determine that one of the following things is true:
1. mywebsite.com has a 'meta name="go-import"' html tag in it when accessed by the go tool that points to a git repo/svn repo/etc, and the contained package has the folder structure "foo/bar/baz/v2/fizz"
2. mywebsite.com/foo has a 'meta name="go-import"' html tag...
(several obvious cases omitted)
3. mywebsite.com/foo/bar/baz is a git repo that has no version tag, but has a "v2" folder in it
4. mywebsite.com/foo/bar/baz is a git repo that has a version tag with v2.x.y
5. the go.mod has a replace or other directive for this import path
The 4th case is the relevant one here. github.com/foo/bar/v2 means that the bar repo has a v2 tag usually.
So, what version of that repo is used if there's v2.0.0 and v2.1.0? Well, the version is the smallest version that you or any module you depend on uses, so you simply have to recursively parse all go.mod files to understand the version used. Much simpler than Cargo.lock.
How do you enable or disable features in a sub-go-module? Let's say I have a module that has a "+ui" or "-ui" build tag because you can optionally build an openGL ui or such.
In rust, this would be a 'features = [ "ui" ]' in your Cargo.toml. In go, you would change your own compilation step to be "go build -tags ui"... And if you have two dependencies with those flags, and you wish to make them opposite values, that is simply impossible in go even though it's trivial in rust.
There are other differences, but I feel like I've already made my point. My main point is that go modules make import paths way more opaque. It used to be that every path element was either part of the import path or a folder on the filesystem. Now, it's either part of the import path, or a git tag, or a folder, and none of those things are obvious.
My secondary point is that go has a much simpler set of requirements than rust, mostly due to missing important features rust has.