Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: [modules + integration] go mod buildrequires, list the build requirements of a set of unpacked modules #31300
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
This kind of analysis is required to populate build environments in CI/CD systems accurately, either to complete the set with other modules, or make sure it is self-hosting before a CI/CD run.
¹ The experimental code is probably horrible. That's not the point. Most of its functions are generic and should have been provided by generic Go tooling in the first place.
² Initial import represents the bulk of the work, keeping the module updated once imported is a lot more reasonable.
⁴ Sometimes, interrupting before the end of the presentation of Go module changes
In general, you are asking for a whole bunch of low-level tools that depend on specific details of today's implementation. We do not want to expose any of those, because they may well not apply to tomorrow's implementation. We should have a discussion about what Linux distributions should do as far as modules are concerned. Posting a sequence of issues asking for specific low-level commands assumes a specific solution to that general problem and puts the cart before the horse.
@rsc The intent is precisely to isolate Linux distributions from Go Modules low-level implementation details, to allow this implementation to evolve freely, without breaking distribution tools every release.
The command set basically describes the CLI API we use to interface with language (python, perl, java, ruby, rust, js…) and non language (fontconfig, ctan, icon…) component systems. We, unfortunately, do not have a nice comprehensive interface design spec. Interfacing grew organically over time, as component systems gained new capabilities distribution and language side. And, it is relatively unusual to onboard a whole full-fledged component system like Go modules in a single step (most languages construct their component systems progressively).
Also, I took the time to check each listed part was actually needed and compatible with the Go module design, and to translate rpm concepts to the Go module equivalent. But there's absolutely nothing in there specific to the current Go module implementation (nor specific to Go nor rpm in general).
So unless Go starts doing very weird and unusual things this command set should be sufficient for its present and future needs. And if it starts doing radically different things, the command interface can always be extended (as long as those new things are compatible with distribution objectives and core design decisions).
If the command set is fully implemented, we won't have to dig deep inside the Go Module code to implement custom replacements, and you can evolve this code at will without breaking Go integration distribution-side. If it's not fully implemented we’ll request the Go API parts needed to implement it ourselves.
To illustrate, this recent example showcases how it all works out for a rust (to take something roughly similar to Go). The
lines in the middle are equivalent to the