-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
EPIC: Separate all SDK modules into standalone go modules #11899
Labels
T:Epic
Epics
Comments
tac0turtle
changed the title
Separate all SDK modules into standalone go modules
EPIC: Separate all SDK modules into standalone go modules
May 9, 2022
This was referenced May 9, 2022
19 tasks
This was referenced May 20, 2022
19 tasks
19 tasks
mergify bot
pushed a commit
that referenced
this issue
Jun 8, 2022
## Description ref: #12084, #11899 --- ### 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... - [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/main/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [ ] reviewed "Files changed" and left comments if necessary - [ ] confirmed all CI checks have passed ### 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... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable)
19 tasks
|
This was referenced Aug 14, 2024
Closed
This was referenced Aug 22, 2024
This was referenced Aug 30, 2024
This was referenced Sep 12, 2024
This was referenced Sep 25, 2024
12 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Overview
This issue outlines a roadmap for breaking up all of the
x/...
SDK modules andsimapp
into standalone go modules using the app wiring design .Problem Definition
The key culprit of the SDK not being decomposable into separate go modules is the dependency on
simapp
.simapp
imports every module but every module and most packages also importsimapp
into their tests. Overall there are 184 references tosimapp
in other packages (runCode > Analyze Code > Backwards Dependencies…
onsimapp
in Goland or IntelliJ to create this report). The reason for such widespread usage of simapp in tests is because there needs to be a way to do integration tests in the SDK and simapp provides the key test fixture. Unfortunately, this creates a Gordian knot where all the modules depend on each other and breaking them up is almost impossible. App wiring provides a solution to this problem by creating a way to quickly spin up integration test fixtures locally in each module rather than using a single SDK wide test fixture that brings all these problems.Phase 1: App Wiring MVP
In this first phase, we create an MVP of app wiring that has these requirements:
x/nft
) to not depend on simapp at all for testing or any other reasonsimapp/app.go
to use the new app wiring while still wiring up everything else as before - this is required to make the app wiring migration gradual and opt-inFor now, the app wiring framework that we will create will forego dealing with any of the messy issues related to protobuf generated code and semantic versioning. This means basically that app wiring will use the global protobuf registry for decoding the app config and the existing gogo proto-based
codec
package will be used elsewhere.Phase 2: Decouple modules and packages from simapp
Following the patterns demonstrated in
x/nft
do the same for each module and package which depends onsimapp
in the SDK, essentially:Module
config message and register a module implementation withappmodule.Register
migrate CLI tests to useSuperseded by EPIC: Unit Testing of Modules via Mocks #12398appconfig
migrate simulations and any other code requiring simappSuperseded by EPIC: Unit Testing of Modules via Mocks #12398Modules should be migrated starting with those with fewer dependencies on other modules first.
x/upgrade
to use app wiring #12298x/evidence
to use app wiring #12238x/auth
to use app wiring #12302x/distribution
to app wiring #12292x/mint
to use app wiring #12234x/gov
to use app wiring #12274vesting
to use app wiring #12300These other issues can also be addressed incrementally during phase 2:
core/appconfig
documentation #12237As this work proceeds, simapp itself can be refactored to use its
app.yaml
more and more - this can be done incrementally as each module is migrated or at the end when simapp is standalone.Other packages besides the
x/*
modules depend onsimapp
as well, usually to callsimapp.MakeTestEncodingConfig()
orsimapp.DefaultConsensusParams()
.DefaultConsensusParams
should have been moved in Phase 1, butMakeTestEncodingConfig
may require app wiring because it used to build a codec with some modules registered. A strategy for decoupling the following packages fromsimapp
will need to be created:baseapp
->simapp
#12535client
->simapp
#12544codec
->simapp
#12528crypto
->simapp
#12612server
->simapp
#12619testutil
->simapp
#12546types
->simapp
#12584At this point, a review of all the migrated modules should be performed. The review should verify the tests coverage and the test behaviors is kept unchanged compared to before the migration.
Phase 3: Make simapp a standalone go module
Instructions in https://github.com/golang/go/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository must be followed. Also, we want to make tags off of a release branch, not
main
. It is expected that these steps will be required:github.com/cosmos/cosmos-sdk/simapp
which importsgithub.com/cosmos/cosmos-sdk
probably using areplace
tag to start. Any remaining dependencies of the rest of the SDK on simapp must be removed by nowPhase 4: Make all modules standalone
Again following the instructions from https://github.com/golang/go/wiki/Modules#is-it-possible-to-add-a-module-to-a-multi-module-repository and starting with the modules with the fewest dependencies to the most.
List of To-dos when creating a
go.mod
: https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#gomodPhase 5
NOTE: it may not be possible to move all modules out of the core go module with this strategy alone because of other cyclic dependencies between each other (such as
x/auth
andx/bank
). Other strategies may be needed or there may be an inseparable set of modules that stay in the SDK for now and are decoupled later if needed.The text was updated successfully, but these errors were encountered: