[DNM] some experimenting with go.work instead of replace rules#50947
Draft
thaJeztah wants to merge 4 commits intomoby:masterfrom
Draft
[DNM] some experimenting with go.work instead of replace rules#50947thaJeztah wants to merge 4 commits intomoby:masterfrom
thaJeztah wants to merge 4 commits intomoby:masterfrom
Conversation
Member
Author
|
Ah, interesting 🤔 |
Using a `go.work` file lets us use the local (unreleased) `api` and `client` modules during development without having to add `replace` directives in `go.mod` (which have to be removed for releases). Unlike `replace` rules, `go.work` is not transitive, so not visible to users of the module (which *will* mean that unreleased versions of the client or "v2" module may be non-functional if they depend on changes in the api or client that are not yet release, and not yet reflected in their `go.mod`). Use `GOWORK=off` to verify what "external" users see. Signed-off-by: Sebastiaan van Stijn <[email protected]>
Disable workspace when tidying the api and client modules to prevent
common dependencies between other modules in the workspace from affecting
the other modules. This allows us to stick to MVS for the api and client
modules, while still updating the main ("v2") module's dependencies.
Signed-off-by: Sebastiaan van Stijn <[email protected]>
This makes the vendor directory reflect what's specified in go.mod; downside is that this may make the code non-buildable without go.work enabled (as the vendor directory doesn't reflect what go.work uses), but it does reduce code-churn w.r.t. vendored files being removed while go.work is present. Possibly we can make vendor handle generating a pseudo-version and update the vendor "as usual" without using a replace rule, but that needs to be looked into if there's an option for that. Signed-off-by: Sebastiaan van Stijn <[email protected]>
Basically, let them work as if GOWORK=off Signed-off-by: Sebastiaan van Stijn <[email protected]>
thaJeztah
force-pushed
the
use_go_work
branch
from
e5de5ed to
2566b5b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This was a branch where I started to look at options when using
go.workinstead of replace rules;go.work, the "local" modules are not vendored while in go workspace mode (see first commit); this means that it's not needed to re-vendor when making changes that impact multiple modules.go.workexists, the vendor directory does not match what's ingo.modapi/,client/) modules (that don't usevendor) it also means that the version ingo.modmay not be the required minimum version.replace, where the module versions are not updated, but the code isgo.mod, and do avendorbefore tagging. The "update the module versions ingo.mod" is not new, but thevendor(bringing back all files that were removed IS, and causes much code-churn).There's some other issues;
go workspacemode, all three modules (api, client, and "v2") are put in the same "workspace"; this will result in dependencies AND go version of theapiandclientmodules to be "bumped" if they are bumped in thev2module.apiandclientmodules, unless they MUST be updated.To prevent the vendor-churn, while still taking advantage of
go.work, I also tried to disablego.workduring vendoring; this would allow updating the dependency versions when needed, while (for development) thego.workallows building the binaries using the local code.This does NOT fix situations where the
apiandclientmodules may be non-functional between releases (i.e., if theclientrequires a newer version of theapimodule than is specified ingo.mod).❓ Can we somehow make such updates happen as part of PRs that merge changes that require the version in
clientto be updated?❓ We can probably generate a pseudo-version for those, but not sure if we can before the PR is merged.
- What I did
- How I did it
- How to verify it
- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)