/ go Public
cmd/go: [modules + integration] go mod requires, list the direct requirements for using a module #31308
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
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.
Go needs an official
go mod requirescommand that processes packed Go module file and returns the list of dependencies needed to use this module in other code.
go mod requirescould be implemented as a
go mod graphmode, 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, after
go mod buildrequiresanalysis.
this is pretty much what
go mod graphalready does, except that this issue asks for a finer-grained dependency view. So it would be a natural
go mod graphextension, and only requires a separate subcommand if there is a wish to keep
go mod graphoutput 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 modulethat 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 requirescall, 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: