If my central package repo had genuinely reproducible builds, such that I could download the source, run the build process and know that I had the same output that the repo held, then I think that I would love to have a setup where:
- I could "add a dependency" by having an automated process that downloads the source, commits it as its own module (or equivalent) in my source repo, tags it with the versioned identifier of the package, and then builds it to make sure it matches what the package repo holds.
- I could make local modifications to the package if I needed to, and my source control would track my deviation from the tagged base version
- I could upgrade my package by re-running the first step, potentially merging it with my local changes.
Hmm, I think I just described the ultimate end state for Go package management...
It works primarily because code health is a number one goal here, everything goes through rigorous mandatory code review, nothing submits into the repository without running all affected test targets, and the goal is that everyone can pretty much "always" (for various definitions) build off head.
And also that there be no walls between teams and projects and code sharing is a universal value across the company. At least outside of Chrome/Android, which are in their own worlds.
This works because the interests of developers of the dependency and the dependent part are aligned, or can be aligned/decided in the case of conflicting interests.
For the rest of us, we need the practical ability to simply make changes that might break dependencies, because of that the ability to fixate to specific old versions, and the ability to create alternate/forked incompatible versions - simply because it allows people to go/develop in the direction they want without being tied down by others who may want a different direction or even no direction at all, because it's not maintained anymore.
The main reasons (as usually is the case) are social/political, not technical.
If my central package repo had genuinely reproducible builds, such that I could download the source, run the build process and know that I had the same output that the repo held, then I think that I would love to have a setup where:
- I could "add a dependency" by having an automated process that downloads the source, commits it as its own module (or equivalent) in my source repo, tags it with the versioned identifier of the package, and then builds it to make sure it matches what the package repo holds.
- I could make local modifications to the package if I needed to, and my source control would track my deviation from the tagged base version
- I could upgrade my package by re-running the first step, potentially merging it with my local changes.
Hmm, I think I just described the ultimate end state for Go package management...