cmd/go: [modules + integration] go mod requires, list the direct requirements for using a module #31308
Labels
modules
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
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 needs an official
go mod requires
command that processes packed Go module file and returns the list of dependencies needed to use this module in other code.go mod requires
could be implemented as ago mod graph
mode, via specific option flags, or as a separate subcommand.It is the pendant of
go mod buildrequires
(#31300) and used by the CI/CD system to populate the job runtime environment, aftergo mod buildrequires
analysis.Constrains
Motivation
this is pretty much what
go mod graph
already does, except that this issue asks for a finer-grained dependency view. So it would be a naturalgo mod graph
extension, and only requires a separate subcommand if there is a wish to keepgo mod graph
output holistic and unfiltered.the finer grained view is needed because populating a CI/CD build environment with more code, than the strict minimum the run will need, gets prohibitively expensive in run time, for busy build farms with a huge list of jobs to run. Therefore the build requirement list needs to be as cut down as possible, allowing to remove the requirements unneeded on a particular GOOS/GOARCH. GOOS/GOARCH is the finest filtering mode, that allows module reuse. GOOS/GOARCH is a constrain shared by all the other code that may wish to reuse the module. That is not the case of other project-specific build tags.
in integration mode, any
go module
that already went through the CI/CD integration pipeline, and has been accepted in the project baseline, already passed all its unit tests, therefore injecting the dependencies of those unit tests in jobs, that reuse this module, is unnecessary and undesirable.missing modules will typically be populated from the organisation baseline. Because this baseline can be shared between organisation projects, it won't be mirrored in each project VCS in a vendor directory.
needed modules, identified by the
go mod requires
call, will typically be populated from the organisation baseline.adding new modules to the organisation baseline is a lot of work². It requires
therefore, there was violent disbelief and rejection among consulted integrators³, of any Go module setup, that forced them to process new modules just because the corresponding imports exists in module parts they have no use for:
The text was updated successfully, but these errors were encountered: