| commit | 4be982bcc49d69e202fcb02aee4d80ce195aee1b | [log] [tgz] |
|---|---|---|
| author | Jay Conrod <jayconrod@google.com> | Wed Aug 18 15:21:08 2021 -0700 |
| committer | Jay Conrod <jayconrod@google.com> | Thu Sep 02 22:33:49 2021 +0000 |
| tree | 33d37622ceeaf288ea27f48bd48a8af75f344add | |
| parent | 1b1db11ec8f43eeafa9418698423dc637655ff0c [diff] |
modfile: in SetRequireSeparateIndirect, arrange requirements consistently SetRequireSeparateIndirect now makes a stronger attempt to keep automatically added requirements in two blocks: one containing only direct requirements and one containing only indirect requirements. SetRequireSeparateIndirect will find or add these two blocks (commented blocks are left alone). New requirements are added to one of these two blocks. Existing requirements may be moved between these two blocks if their markings change. SetRequireSeparateIndirect attempts to preserve existing structure in the file by not adding requirements to or moving requirements from blocks with block-level comments and blocks other than the last uncommented direct-only and indirect-only block. As an exception to aid with migration, if the file contains a single uncommented block of requirements (as would the be the case if the user started with a 1.16 go.mod file, changed the go directive to 1.17, then ran 'go mod tidy'), SetRequireSeparateIndirect will split the block into direct-only and indirect-only blocks. This is a change in behavior, but it has no semantic effect, and it should result in cleaner, more stable go.mod files. For golang/go#47563 For golang/go#47733 Change-Id: Ifa20bb084c6bdaf1e00140600380857de8afa320 Reviewed-on: https://go-review.googlesource.com/c/mod/+/343431 Trust: Jay Conrod <jayconrod@google.com> Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
This repository holds packages for writing tools that work directly with Go module mechanics. That is, it is for direct manipulation of Go modules themselves.
It is NOT about supporting general development tools that need to do things like load packages in module mode. That use case, where modules are incidental rather than the focus, should remain in x/tools, specifically x/tools/go/packages.
The specific case of loading packages should still be done by invoking the go command, which remains the single point of truth for package loading algorithms.