Open nim-nim opened 5 years ago
FYI, as of now, there are currently 7 or so related issues filed today. See for example this search on open issues authored by @nim-nim.
CC @bcmills @rsc
@thepudds Thanks for the ping. I still have a few more to write, it takes time to put things into order and write a coherent report.
@thepudds @bcmills @rsc Since the generic issue boilerplate references issue #29452, it has an up-to-date list of all the reports I filled.
Short-term the only remaining showstopper for is issue #31304. I know how to workaround or get by without the others, in degraded mode¹.
Mid to long-term local workarounds and degraded mode are a terrible strategy. Once the language is no longer new and shiny (which will eventually happen to Go), people will actively resist getting involved in something that makes their integration work an obstacle course, and people already involved will migrate to bluer skyes. It’s not a single issue problem, it’s a death by a thousand papercuts problem, where each small tooling misbehaviour and missing functionnality contributes to human rejection.
¹ Workaround means reimplementing the Go tooling:
build.ImportDir
without go list
,modfile.Parse
instead of relying on go mod
,(also, issue #31304 is something more in @jcajka’s ballpark than mine Fedora-side, since it touches directly the go compiler behaviour)
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: