-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: go workspaces #12675
feat: go workspaces #12675
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I am super not up to speed with go workspaces, but the more I read about it, the less I am sure we should commit a go.work
and go.work.sum
at all.
- https://go.googlesource.com/proposal/+/master/design/45713-workspace.md#preventing-files-from-being-checked-in-to-repositories
- cmd/go: add a workspace mode golang/go#45713
- github/gitignore@fbc053f#commitcomment-73352144
- cmd/go: add documentation for go.work.sum golang/go#51941
From my understanding, that is just for avoiding committing the replace
s like these https://github.com/cosmos/cosmos-sdk/blob/main/go.mod#L282-L287.
We should avoid having any replace anyway (these) and start tagging our changes. Which means when we need a feature, first update the needed module, and then use that feature.
Otherwise, it seems like we should add GOWORK=off
for our build, but this seems hacky. Maybe this is something we should all use locally but never commit, for ensuring every module are always up-to-date and tagged as they should be. Something to have in https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md instead, and actually add go.work
and go.work.sum
in the .gitignore
?
If I am saying something wrong, please correct me, I am still learning and reading about this feature.
I would gladly have @aaronc or maybe even @matloob input on this one.
@julienrbrt you may be 100% correct here. I'm not sure. The biggest benefit I observed was that go work sync replaces the go-mod-tidy-all.sh script and that it makes my vscode a lot happier. I guess another thing I'd like to see us avoid is becoming a module soup like libp2p, but i suppose there's a question on that: will go workspaces help us to avoid module-soupification? |
@julienrbrt -- from my (limited) experience working with Go workspaces, I think that you may have one thing wrong. I (think) they're designed for monorepo situations like the cosmos-sdk, and yes, they ought to replace the replace statements, but also, maybe most importantly they'll give developer's editors (like vscode) some information about the sdk so that the editor's usual features work correctly. So, overall, I do think that we would want to commit a go.work and a go.work.sum -- but .... I'm definitely not certain of any of this. One thing that I can say with decent certainty is that I don't think that this does us any harm, and may make editing easier. Maybe check out additional comments in #11450 :). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, I see the advantage for main
. However, I do think this should not make it in a release. Instead, we should remove it and tag the modules.
This means we need to update the RELEASE_PROCESS.md
to reflect that.
@julienrbrt -- since this is now passing every test (honestly for reasons I don't fully understand) -- I think that it makes sense to merge. I think that it will make working on and with the sdk easier. If it doesn't then I figure we just pull it out. wdyt? |
Just curious, it is normal that these replace are still there https://github.com/notional-labs/cosmos-sdk/blob/11b3d8b555b1121866b90dca8671d61fb3d9a2d7/go.mod#L284-L289? |
@julienrbrt -- I don't know. Happy to play around a bit locally on that & revert w/ info. |
Unsure of this-- depends what we want... LIkely we do tag the modules anyway, because iirc the idea is to have idependent release schedules for them. hmmmmm inconclusive, will think some This means we need to update the RELEASE_PROCESS.md to reflect that. |
@julienrbrt I played around, result is: I think that we need replaces, but only for the modules that we publish at cosmossdk.io The others can be removed, and I figure that it makes sense to do so, so I'm updating this to reflect that. i was incorrect! heh-- so I think we need all of them otherwise we get: go: github.com/cosmos/cosmos-sdk/store/tools/[email protected]: invalid version: unknown revision 000000000000 I'll try a mod tidy all then a work sync and see if that makes it happier... |
ok, might have a solution to some of the replaces. Our replaces may be breaking psseudo-versions. The question is then: Do we want the sdk's main branch to always use the versions of modules that are also in main? If we keep the replaces, that's what'll happen. If we remove them, main will import a specific version of those modules. |
Do we need to tag a few go modules then (as beta)? This is long overdue anyway. |
but, 3rd update: I can get rid of the replaces... I'll push, and would love to hear your opinion. 10m maybe |
I think it'll help you to see my terminal log.... Functionally-speaking, the replaces (all of them) were ensuring that I've now got a go.mod without replaces. Context: The replaces were stopping go get, etc from peoperly making pseudo-versions. The solution was to This seems to do / work how we would like it to.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks! lgtm! I am still not sure if we should update the release process for describing that we remove the go.work
and go.work.sum
when cutting a new release.
go.mod
Outdated
@@ -65,7 +65,7 @@ require ( | |||
sigs.k8s.io/yaml v1.3.0 | |||
) | |||
|
|||
require github.com/cosmos/cosmos-sdk/store/tools/ics23 v0.0.0-00010101000000-000000000000 | |||
require github.com/cosmos/cosmos-sdk/store/tools/ics23 v0.0.0-20220726092710-f848e4300a8a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit can we merge this require block with the one above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes we can
Let's remember this issue when we need to release a new version and decide the process. Merging now. Thanks @faddat! |
@@ -108,7 +101,7 @@ require ( | |||
github.com/tendermint/btcd v0.1.1 // indirect | |||
github.com/tendermint/crypto v0.0.0-20191022145703-50d29ede1e15 // indirect | |||
github.com/tendermint/go-amino v0.16.0 // indirect | |||
github.com/tendermint/tendermint v0.34.20 // indirect | |||
github.com/tendermint/tendermint v0.35.9 // indirect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should figure out where this upgrade is coming from. We should have the whole repo on 0.34.20
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I was checking exactly that in #12741. It turns out if we go mod tidy
in ./cosmovisor
right now we get an error. If we remove these indirect imports and go mod tidy
it will put it back to 0.34.20
. However, as soon as we go work sync
this forces cosmovisor to have tm 0.35.9
as indirect dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need cosmovisor to be included in the go.work
anyway, as cosmovisor
is not used by the sdk. Investigating...
Description
A much better, cleaner go workspaces PR.
In the previous state, the replaces in go.mod were keeping Go from making pseudo versions that referenced an exact commit properly. Once I got the pseudo versions in using
go get
, things worked great.Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change