x/build/cmd/updatestd: investigate a package-first update strategy, instead of module-first #41589
Patch set 1 of CL 256357 implemented a per-module update strategy for golang.org/x dependencies in the std and cmd standard library modules. At a high level:
This issue is about investigating modifying the strategy to perform the update on a per-package level.
What I'm imagining (but is incomplete and untested) is roughly:
This is the tracking issue for investigating and implementing this as needed, and discussing the approach. It should be easier to do that here than in a code review.
I don't want to do this work now because there isn't a need yet (and I have higher priority work). But this will come up in the future. Filing an issue in the meantime.
The text was updated successfully, but these errors were encountered:
I've spent some time thinking about this suggestion, and I understand it a lot better now. I also agree that a package-centric approach, if it is made robust, can be better and cleaner. However, I discovered a problem with it.
While trying to implement this new approach, I realized there is a potential pitfall: when using
(In theory, a package may have different dependencies depending on GOOS, GOARCH, CGO_ENABLED, and even compiler gc vs gccgo, since these all affect which .go files are selected.)
As far as I know,
@bcmills Doe this make sense to you? Have you considered this factor? Do you have any suggestions for how we can make a package-centric approach work?
Here is a strategy I am currently imagining if such a hypothetical flag is supported:
The outcome of this strategy seems good, but it is looks quite complicated to implement and maintain.
I'm not sure how lazy module loading (#36460) intersects with this. Maybe it will make it possible to implement this more simply after that's done?