This change will not affect consumers of the library. Dependency management tools ignore the dependency management configs of imported packages.
Go modules significantly improve the developer experience by alleviating much of the dependency hell that arrises from working on multiple go projects at once. The pain point is almost always related to the fact that before modules, the compiler expects to find one and only one version of a dependency in the GOPATH. As the library deliberately does not manage vendor/, this means that developers are often having to cross the minefield that is the kubernetes versioned tool dependencies (client-go, apimachinery, etc) when they initialize their local env (dep ensure).
Secondly, go mods add a convenient method for substituting canonical import paths of go projects through the replace go.mod directive. Replacements can be both working branches of forked repos or a relative path to the code on the host system. This allows for code changes in the local copy of the library (on a forked repo and/or a working branch) to be built from directly by the dependee project. This is far less messy than the current work flow, which is to copy/paste the entire library into the dependee's vendor directory in order to rebuild.
To enable this replace behavior, go mod expects a go.mod file to exist in the dependency. It does not work otherwise.
Activating a replace from a repo fork and working branch can be done via the CLI.
go mod edit --replace=github.com/kube-object-storate/lib-bucket-provisioner=github.com/myFork/lib-bucket-provisioner@myWorkingBranch
Followed by
go mod tidy
or for a local path:
go mod edit --replace=github.com/kube-object-storate/lib-bucket-provisioner=relative/PathTo/lib-bucket-provisioner
Nothing else is required for local paths.
jeffvance
commented
4 years ago
This change will not affect consumers of the library. Dependency management tools ignore the dependency management configs of imported packages.
Go modules significantly improve the developer experience by alleviating much of the dependency hell that arrises from working on multiple go projects at once. The pain point is almost always related to the fact that before modules, the compiler expects to find one and only one version of a dependency in the GOPATH. As the library deliberately does not manage
vendor/, this means that developers are often having to cross the minefield that is the kubernetes versioned tool dependencies (client-go, apimachinery, etc) when they initialize their local env (dep ensure).Secondly, go mods add a convenient method for substituting canonical import paths of go projects through the
replacego.mod directive. Replacements can be both working branches of forked repos or a relative path to the code on the host system. This allows for code changes in the local copy of the library (on a forked repo and/or a working branch) to be built from directly by the dependee project. This is far less messy than the current work flow, which is to copy/paste the entire library into the dependee's vendor directory in order to rebuild.To enable this replace behavior,
go modexpects a go.mod file to exist in the dependency. It does not work otherwise.Activating a replace from a repo fork and working branch can be done via the CLI.
go mod edit --replace=github.com/kube-object-storate/lib-bucket-provisioner=github.com/myFork/lib-bucket-provisioner@myWorkingBranchFollowed bygo mod tidyor for a local path:
go mod edit --replace=github.com/kube-object-storate/lib-bucket-provisioner=relative/PathTo/lib-bucket-provisionerNothing else is required for local paths.