This report is part of a series, filled at the request of @mdempsky, focused at making Go modules integrator-friendly.

Please do not close or mark it as duplicate before making sure you’ve read and understood the general context. A lot of work went into identifying problems points precisely.

Needed feature

go mod tidy needs to optionally operate on a specific *.mod module descriptor file.

Constrains

• the command needs to operate both on:
  • unpacked module trees (with go.mod located at the tree root) and
  • packed modules (with the module descriptor filename matching the zip payload filename)
• the module descriptor filesystem path should be specifiable explicitly
  • all the levels of caching and abstraction in the Go module design, make matching by module path (+ module version) tricky for humans. It is very likely the go command will find some other module in its cache to work on, instead of using the one the human intended.
  • implicit descriptor matching like is the case right now does not work for packed modules
    • several versions of the same module can be deployed in the same directory in packed mode, as specified in goproxy
• the feature should also be exposed as a function in the official Go API
• the command should work in secure no-internet-download mode. In that mode it should probably restricts its processing to direct dependencies and the dependencies available in configured goproxy sources (cmd/go: [modules + integration] use several goproxy sources simultaneously #31304)

Motivation

Curating a module for use in an integration baseline may result in:

• culling dead or unnecessary module code, or
• patch it it to use different imports, targeting a new API version or a different fork of the same original project

This will invalidate part of the dependency information in the upstream go.mod file. In fact, retargetting dependencies to something saner, part of the integrator baseline, is often the whole point of the curating process.

It is undesirable to recompute the new module descriptor before all the curating operations in the CI/CD job have finished. As long as the module has not been packed, some modifications can still occur. Therefore, the correct and safe go mod tidy target is the packed module fileset.

Trying to schedule descriptor tiding before the packing has finished is unreliable, because some of the culling can occur directly during zip payload writing time. That is not the case for go mod pack, as specified in #31302, but it is the case for modist.