The current go dependency management is lacking: - If you want to make a change in one of your dependencies, you have to fork the repository, and in the forked

The current go dependency management is lacking: - If you want to make a change in one of your dependencies, you have to fork the repository, and in the forked repository you have to textually rename the package to the new name. This makes for abysmal maintenance and unneeded merge conflicts if you want to maintain parity with upstream code. - There is the go replace directive, but this does not transitively apply to dependencies of the module that declares the go replace directive. - If your patch gets into the upstream repository, now you have to undo the forking (again via a large textual rename). - If a dependency of your code and your code both depend on the same package, you are forced to take one version per binary that gets compiled. This is just plain absurd and leads to situations where you cannot bump the dependencies independently. If you have a tree of these dependencies, you must update each dependency in the order that respects the dependency tree. This sort of defeats the purpose of specifying and locking the dependency version. - Overall, go was designed for a mono-repo in a company (Google) that does not version their software (everything runs at tip), and it shows in any type of effort that attempts to re-use software in non-trivial fashion, with distributed development that happens at different rates in different repositories.