Skip to content

Commit 3af1062

Browse files
committed
Modules: clarify 1.22+ conversions from gopkg.lock
1 parent 8bd0c75 commit 3af1062

File tree

1 file changed

+9
-1
lines changed

1 file changed

+9
-1
lines changed

Modules.md

+9-1
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,11 @@ Since [Go 1.14](https://go.dev/doc/go1.14), module support is considered ready f
1212

1313
## Recent Changes
1414

15+
### Go 1.22
16+
See the [Go 1.16 release notes](https://go.dev/doc/go1.22#go-command) for details.
17+
18+
* `go mod init` no longer attempts to import module requirements from configuration files for other vendoring tools (such as `Gopkg.lock`)
19+
1520
### Go 1.16
1621

1722
See the [Go 1.16 release notes](https://go.dev/doc/go1.16#go-command) for details.
@@ -347,7 +352,6 @@ To create a `go.mod` for an existing project:
347352
```
348353
$ go mod init
349354
```
350-
This step converts from any existing [`dep`](https://github.com/golang/dep) `Gopkg.lock` file or any of the other [nine total supported dependency formats](https://tip.golang.org/pkg/cmd/go/internal/modconv/?m=all#pkg-variables), adding require statements to match the existing configuration.
351355

352356
`go mod init` will often be able to use auxiliary data (such as VCS meta-data) to automatically determine the appropriate module path, but if `go mod init` states it can not automatically determine the module path, or if you need to otherwise override that path, you can supply the [module path](/wiki/Modules#gomod) as an optional argument to `go mod init`, for example:
353357

@@ -357,6 +361,8 @@ To create a `go.mod` for an existing project:
357361

358362
Note that if your dependencies include v2+ modules, or if you are initializing a v2+ module, then after running `go mod init` you might also need to edit your `go.mod` and `.go` code to add `/vN` to import paths and module paths as described in the ["Semantic Import Versioning"](/wiki/Modules#semantic-import-versioning) section above. This applies even if `go mod init` automatically converted your dependency information from `dep` or other dependency managers. (Because of this, after running `go mod init`, you typically should not run `go mod tidy` until you have successfully run `go build ./...` or similar, which is the sequence shown in this section).
359363

364+
If used with go 1.21.13 or older, this step also converts from any existing [`dep`](https://github.com/golang/dep) `Gopkg.lock` file or any of the other [nine total supported dependency formats](https://tip.golang.org/pkg/cmd/go/internal/modconv/?m=all#pkg-variables), adding require statements to match the existing configuration.
365+
360366
3. Build the module. When executed from the root directory of a module, the `./...` pattern matches all the packages within the current module. `go build` will automatically add missing or unconverted dependencies as needed to satisfy imports for this particular build invocation:
361367

362368
```
@@ -1320,6 +1326,8 @@ If `go mod init` gives you this error, those heuristics were not able to guess,
13201326
13211327
Yes. This requires some manual steps, but can be helpful in some more complex cases.
13221328
1329+
Go versions 1.21 and older attempted to convert a prior dependency manager formats to `go.mod` formats. The following instructions thus need 1.21.13 or older; you need to run the following with `GOTOOLCHAIN=go1.21.13`, or install an older version of go manually.
1330+
13231331
When you run `go mod init` when initializing your own module, it will automatically convert from a prior dependency manager by translating configuration files like `Gopkg.lock`, `glide.lock`, or `vendor.json` into a `go.mod` file that contains corresponding `require` directives. The information in a pre-existing `Gopkg.lock` file for example usually describes version information for all of your direct and indirect dependencies.
13241332
13251333
However, if instead you are adding a new dependency that has not yet opted in to modules itself, there is not a similar automatic conversion process from any prior dependency manager that your new dependency might have been using. If that new dependency itself has non-module dependencies that have had breaking changes, then in some cases that can cause incompatibility problems. In other words, a prior dependency manager of your new dependency is not automatically used, and that can cause problems with your indirect dependencies in some cases.

0 commit comments

Comments
 (0)