refactor: remove dependency x/module -> sdk through InterfaceRegistry #19652
Conversation
This file contains 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
- refactor modules to use core/registry/LegacyRegistry - update `HasRegisterInterfaces` definition - fix core_module.go usage - rm unused import in mock code - cd simapp/v2 && go mod tidy - mv HasRegisterInterfaces interface to core - fix failing test to conform with mock - use protoiface.MessageV1 in interface registry
github-actions
bot
added
C:x/staking
C:x/gov
C:x/slashing
C:x/distribution
kocubinski
changed the title
WalkthroughWalkthroughThis update signifies a significant overhaul in how interfaces and message types are registered within the Cosmos SDK. By transitioning to Changes
Related issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: .coderabbit.yml
Files selected for processing (55)
- codec/types/interface_registry.go (4 hunks)
- core/appmodule/module.go (2 hunks)
- core/appmodule/v2/appmodule.go (2 hunks)
- core/registry/legacy.go (1 hunks)
- testutil/mock/types_mock_appmodule.go (3 hunks)
- testutil/mock/types_module_module.go (5 hunks)
- types/module/core_module.go (2 hunks)
- types/module/module.go (4 hunks)
- types/module/module_test.go (2 hunks)
- types/msgservice/msg_service.go (1 hunks)
- x/accounts/keeper.go (2 hunks)
- x/accounts/module.go (3 hunks)
- x/accounts/utils_test.go (1 hunks)
- x/auth/module.go (3 hunks)
- x/auth/types/codec.go (2 hunks)
- x/auth/vesting/module.go (2 hunks)
- x/auth/vesting/types/codec.go (2 hunks)
- x/authz/codec.go (2 hunks)
- x/authz/module/module.go (3 hunks)
- x/bank/module.go (3 hunks)
- x/bank/types/codec.go (2 hunks)
- x/circuit/module.go (3 hunks)
- x/circuit/types/codec.go (1 hunks)
- x/consensus/module.go (3 hunks)
- x/consensus/types/codec.go (1 hunks)
- x/counter/module.go (2 hunks)
- x/counter/types/codec.go (1 hunks)
- x/crisis/module.go (3 hunks)
- x/crisis/types/codec.go (2 hunks)
- x/distribution/module.go (3 hunks)
- x/distribution/types/codec.go (2 hunks)
- x/evidence/module.go (3 hunks)
- x/evidence/types/codec.go (2 hunks)
- x/feegrant/codec.go (2 hunks)
- x/feegrant/module/module.go (3 hunks)
- x/genutil/module.go (2 hunks)
- x/gov/module.go (4 hunks)
- x/gov/types/v1/codec.go (2 hunks)
- x/gov/types/v1beta1/codec.go (2 hunks)
- x/group/codec.go (2 hunks)
- x/group/module/module.go (3 hunks)
- x/mint/module.go (3 hunks)
- x/mint/types/codec.go (2 hunks)
- x/nft/codec.go (1 hunks)
- x/nft/module/module.go (3 hunks)
- x/params/module.go (2 hunks)
- x/params/types/proposal/codec.go (1 hunks)
- x/protocolpool/module.go (2 hunks)
- x/protocolpool/types/codec.go (1 hunks)
- x/slashing/module.go (3 hunks)
- x/slashing/types/codec.go (2 hunks)
- x/staking/module.go (3 hunks)
- x/staking/types/codec.go (2 hunks)
- x/upgrade/module.go (3 hunks)
- x/upgrade/types/codec.go (2 hunks)
Additional comments: 122
x/counter/types/codec.go (2)
- 4-5: The import statement has been correctly updated to use
"cosmossdk.io/core/registry"instead of the previoustypes.InterfaceRegistry. This aligns with the PR's objective to decouplex/modulefrom direct SDK dependencies.- 10-10: The
RegisterInterfacesfunction signature has been updated to useregistry.LegacyRegistryas its parameter type. This change is consistent with the PR's goal of enhancing modularity by abstracting the interaction with theInterfaceRegistry. Ensure that all implementations of this interface across the SDK are updated accordingly to maintain compatibility.Verification successful
The verification process confirms that the
RegisterInterfacesfunction signature has been updated to useregistry.LegacyRegistryas its parameter type across various modules of the SDK. This change aligns with the PR's goal of enhancing modularity by abstracting the interaction with theInterfaceRegistry. The widespread implementation of this interface update across the SDK maintains compatibility as intended.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for implementations of RegisterInterfaces to ensure they use the new parameter type. ast-grep --lang go --pattern $'func RegisterInterfaces($_ registry.LegacyRegistry) { $$$ }'Length of output: 16122
x/nft/codec.go (2)
- 4-5: The import statement has been correctly updated to
"cosmossdk.io/core/registry", aligning with the PR's objective to reduce direct dependencies on the SDK by utilizing a more abstracted interaction mechanism.- 11-11: The
RegisterInterfacesfunction now correctly usesregistry.LegacyRegistryas its parameter type, which is part of the effort to abstract the interaction with theInterfaceRegistry. This change should be consistently applied across all modules to ensure compatibility.Verification successful
The verification process confirms that the
RegisterInterfacesfunction consistently usesregistry.LegacyRegistryas its parameter type across various modules in the codebase. This aligns with the effort to abstract the interaction with theInterfaceRegistryand ensures compatibility across all modules.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Ensure consistent use of registry.LegacyRegistry in RegisterInterfaces implementations. ast-grep --lang go --pattern $'func RegisterInterfaces($_ registry.LegacyRegistry) { $$$ }'Length of output: 16122
x/circuit/types/codec.go (2)
- 4-5: The import statement has been updated to
"cosmossdk.io/core/registry", which is in line with the PR's goal to decouple modules from direct SDK dependencies. This change is appropriate and enhances modularity.- 11-11: The
RegisterInterfacesfunction signature has been modified to useregistry.LegacyRegistry, aligning with the objective to abstract the interaction with theInterfaceRegistry. This is a positive change towards achieving a more loosely coupled architecture.Verification successful
The verification process confirms that the
RegisterInterfacesfunction signature, utilizingregistry.LegacyRegistry, has been consistently applied across various modules within the SDK. This aligns with the objective of abstracting the interaction with theInterfaceRegistryand achieving a more loosely coupled architecture. The change has been systematically implemented across different parts of the SDK, indicating a thorough and consistent update.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify consistent application of the new `RegisterInterfaces` signature across the SDK. ast-grep --lang go --pattern $'func RegisterInterfaces($_ registry.LegacyRegistry) { $$$ }'Length of output: 16122
x/protocolpool/types/codec.go (2)
- 4-5: The import statement has been correctly updated to
"cosmossdk.io/core/registry", which supports the PR's goal of reducing direct dependencies on the SDK. This change is consistent with the efforts to enhance modularity.- 10-10: The
RegisterInterfacesfunction now usesregistry.LegacyRegistryas its parameter type, which is part of the broader effort to abstract the interaction with theInterfaceRegistry. This change is crucial for achieving a more modular architecture.Verification successful
The verification process confirms that the
RegisterInterfacesfunction now usesregistry.LegacyRegistryas its parameter type across various implementations within the codebase. This change aligns with the effort to abstract the interaction with theInterfaceRegistryfor a more modular architecture.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Confirm that all `RegisterInterfaces` implementations have been updated to use `registry.LegacyRegistry`. ast-grep --lang go --pattern $'func RegisterInterfaces($_ registry.LegacyRegistry) { $$$ }'Length of output: 16122
x/params/types/proposal/codec.go (2)
- 4-5: The import statement has been updated to
"cosmossdk.io/core/registry", aligning with the PR's objective to decouple modules from direct SDK dependencies. This change is consistent with the efforts to enhance modularity.- 15-15: The
RegisterInterfacesfunction signature has been modified to useregistry.LegacyRegistry, which is in line with the goal of abstracting the interaction with theInterfaceRegistry. This change supports the objective of achieving a more loosely coupled architecture.Verification successful
The verification process confirms that the
RegisterInterfacesfunction signature, utilizingregistry.LegacyRegistry, has been consistently applied across various modules within the SDK. This change aligns with the objective of abstracting the interaction with theInterfaceRegistryand supports the goal of achieving a more loosely coupled architecture.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Ensure that the new `RegisterInterfaces` signature is consistently applied across the SDK. ast-grep --lang go --pattern $'func RegisterInterfaces($_ registry.LegacyRegistry) { $$$ }'Length of output: 16122
x/consensus/types/codec.go (2)
- 4-5: The import statement has been updated to
"cosmossdk.io/core/registry", which is consistent with the PR's goal of reducing direct dependencies on the SDK. This change supports the efforts to enhance modularity.- 12-12: The
RegisterInterfacesfunction signature has been modified to useregistry.LegacyRegistry, aligning with the objective to abstract the interaction with theInterfaceRegistry. This change is a positive step towards achieving a more modular architecture.Verification successful
The verification process confirms that the
RegisterInterfacesfunction signature, utilizingregistry.LegacyRegistry, has been consistently applied across various modules within the SDK. This change aligns with the objective of abstracting the interaction with theInterfaceRegistryand is a positive step towards achieving a more modular architecture.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Confirm consistent application of the new `RegisterInterfaces` signature across the SDK. ast-grep --lang go --pattern $'func RegisterInterfaces($_ registry.LegacyRegistry) { $$$ }'Length of output: 16122
x/mint/types/codec.go (2)
- 4-5: The import statement has been correctly updated to
"cosmossdk.io/core/registry", aligning with the PR's objective to decouple modules from direct SDK dependencies. This change is consistent with the efforts to enhance modularity.- 19-19: The
RegisterInterfacesfunction now usesregistry.LegacyRegistryas its parameter type, which is part of the broader effort to abstract the interaction with theInterfaceRegistry. This change is crucial for achieving a more modular architecture.Verification successful
The verification process confirms that the
RegisterInterfacesfunction now usesregistry.LegacyRegistryas its parameter type across various implementations within the codebase. This aligns with the effort to abstract the interaction with theInterfaceRegistryfor a more modular architecture.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Ensure that all `RegisterInterfaces` implementations have been updated to use `registry.LegacyRegistry`. ast-grep --lang go --pattern $'func RegisterInterfaces($_ registry.LegacyRegistry) { $$$ }'Length of output: 16122
x/slashing/types/codec.go (2)
- 4-5: The import statement has been updated to
"cosmossdk.io/core/registry", which is in line with the PR's goal of reducing direct dependencies on the SDK. This change supports the efforts to enhance modularity.- 20-20: The
RegisterInterfacesfunction now correctly usesregistry.LegacyRegistryas its parameter type, which is part of the effort to abstract the interaction with theInterfaceRegistry. This change is crucial for achieving a more modular architecture.Verification successful
The verification process confirms that all
RegisterInterfacesimplementations across various modules have been updated to useregistry.LegacyRegistryas their parameter type, aligning with the efforts to abstract the interaction with theInterfaceRegistryfor a more modular architecture.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Confirm that all `RegisterInterfaces` implementations have been updated to use `registry.LegacyRegistry`. ast-grep --lang go --pattern $'func RegisterInterfaces($_ registry.LegacyRegistry) { $$$ }'Length of output: 16122
x/crisis/types/codec.go (2)
- 4-5: The import statement has been correctly updated to
"cosmossdk.io/core/registry", aligning with the PR's objective to decouple modules from direct SDK dependencies. This change is consistent with the efforts to enhance modularity.- 20-20: The
RegisterInterfacesfunction signature has been modified to useregistry.LegacyRegistry, which is in line with the goal of abstracting the interaction with theInterfaceRegistry. This change supports the objective of achieving a more loosely coupled architecture.Verification successful
The verification process confirms that the
RegisterInterfacesfunction signature, utilizingregistry.LegacyRegistry, has been consistently applied across the SDK. This aligns with the goal of abstracting the interaction with theInterfaceRegistryand supports a move towards a more loosely coupled architecture.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Ensure that the new `RegisterInterfaces` signature is consistently applied across the SDK. ast-grep --lang go --pattern $'func RegisterInterfaces($_ registry.LegacyRegistry) { $$$ }'Length of output: 16122
core/registry/legacy.go (1)
- 1-25: The introduction of the
LegacyRegistryinterface is a significant change that aligns with the PR's objective of enhancing modularity and maintainability within the Cosmos SDK. This interface abstracts the interaction with theInterfaceRegistry, reducing direct dependencies on specific SDK components. It's crucial to ensure that the documentation for this interface is clear and comprehensive, as it will play a central role in how modules register their interfaces and implementations moving forward.x/evidence/types/codec.go (2)
- 4-4: The addition of
"cosmossdk.io/core/registry"and removal of"github.com/cosmos/cosmos-sdk/codec/types"align with the PR's objective to decouplex/modulefrom direct SDK dependencies. This change is consistent with the goal of enhancing modularity.- 22-22: The change in the parameter type of the
RegisterInterfacesfunction fromtypes.InterfaceRegistrytoregistry.LegacyRegistryis a key part of the refactoring effort. This modification supports the objective of reducing direct dependencies on specific SDK components. Ensure that all modules implementing this interface have been updated accordingly.x/upgrade/types/codec.go (2)
- 4-4: The addition of
"cosmossdk.io/core/registry"import is consistent with the PR's goal to abstract the interaction with theInterfaceRegistry. This change facilitates a more loosely coupled architecture.- 22-22: Updating the parameter type in the
RegisterInterfacesfunction toregistry.LegacyRegistryaligns with the objective of decoupling modules from the SDK's core types. This is a positive step towards enhancing modularity.x/bank/types/codec.go (2)
- 4-4: The addition of the
"cosmossdk.io/core/registry"import is in line with the overarching goal of the PR to reduce direct dependencies on the SDK. This change supports the effort to enhance modularity within the Cosmos SDK.- 24-24: Changing the parameter type for the
RegisterInterfacesfunction toregistry.LegacyRegistryis consistent with the PR's objective. This change contributes to the decoupling of modules from the SDK's core types, promoting a more modular architecture.x/gov/types/v1beta1/codec.go (2)
- 4-4: Adding
"cosmossdk.io/core/registry"to the imports aligns with the PR's goal of abstracting the interaction with theInterfaceRegistry. This change is a positive step towards achieving a more loosely coupled architecture within the Cosmos SDK.- 24-24: The modification of the parameter type in the
RegisterInterfacesfunction toregistry.LegacyRegistrysupports the PR's objective of reducing direct dependencies on SDK components. This change is crucial for enhancing the modularity of the Cosmos SDK.x/auth/vesting/module.go (2)
- 5-5: The import of
"cosmossdk.io/core/registry"is in line with the PR's objective to abstract the interaction with theInterfaceRegistry. This change contributes to the goal of reducing direct dependencies on the SDK, promoting a more modular architecture.- 48-48: Updating the parameter type in the
RegisterInterfacesfunction toregistry.LegacyRegistryaligns with the PR's goal of decoupling modules from the SDK's core types. This is a positive step towards enhancing modularity within the Cosmos SDK.x/counter/module.go (3)
- 7-7: The import of
"cosmossdk.io/core/registry"supports the PR's objective of abstracting the interaction with theInterfaceRegistry. This change is consistent with the effort to reduce direct dependencies on the SDK, enhancing modularity.- 15-16: The implementation of
appmodule.HasRegisterInterfacesinstead ofmodule.HasRegisterInterfacesis a significant change that aligns with the PR's goal of enhancing modularity and maintainability by promoting a more streamlined interface for module interaction.- 50-50: Changing the parameter type for the
RegisterInterfacesfunction toregistry.LegacyRegistryis consistent with the PR's objective of decoupling modules from the SDK's core types. This change contributes to a more modular architecture within the Cosmos SDK.x/distribution/types/codec.go (2)
- 4-4: The addition of
"cosmossdk.io/core/registry"to the imports aligns with the PR's objective to abstract the interaction with theInterfaceRegistry. This change is a positive step towards achieving a more loosely coupled architecture within the Cosmos SDK.- 25-25: Modifying the parameter type in the
RegisterInterfacesfunction toregistry.LegacyRegistrysupports the PR's goal of reducing direct dependencies on SDK components. This change is crucial for enhancing the modularity of the Cosmos SDK.x/feegrant/codec.go (2)
- 4-4: Adding
"cosmossdk.io/core/registry"to the imports is consistent with the PR's goal of abstracting the interaction with theInterfaceRegistry. This change facilitates a more loosely coupled architecture, which is beneficial for the Cosmos SDK's modularity.- 25-25: The change in the parameter type for the
RegisterInterfacesfunction toregistry.LegacyRegistryaligns with the PR's objective of decoupling modules from the SDK's core types. This is a positive step towards enhancing modularity within the Cosmos SDK.x/gov/types/v1/codec.go (2)
- 4-4: The inclusion of
"cosmossdk.io/core/registry"in the imports supports the PR's objective to abstract the interaction with theInterfaceRegistry. This change contributes to the goal of reducing direct dependencies on the SDK, promoting a more modular architecture.- 27-27: Updating the parameter type in the
RegisterInterfacesfunction toregistry.LegacyRegistryaligns with the PR's goal of decoupling modules from the SDK's core types. This is a positive step towards enhancing modularity within the Cosmos SDK.x/authz/codec.go (2)
- 4-4: The addition of
"cosmossdk.io/core/registry"to the imports is in line with the PR's objective to abstract the interaction with theInterfaceRegistry. This change is a positive step towards achieving a more loosely coupled architecture within the Cosmos SDK.- 26-26: Changing the parameter type for the
RegisterInterfacesfunction toregistry.LegacyRegistrysupports the PR's goal of reducing direct dependencies on SDK components. This change is crucial for enhancing the modularity of the Cosmos SDK.x/auth/types/codec.go (2)
- 4-4: The import of
cosmossdk.io/core/registryaligns with the PR's objective to decouplex/modulefrom direct SDK dependencies by utilizing a more abstracted interaction with theInterfaceRegistry.- 31-31: The change in the
RegisterInterfacesfunction to useregistry.LegacyRegistryinstead of a direct SDK type is a positive step towards achieving modularity and reducing direct dependencies on the SDK. This change supports the broader goal of enhancing the maintainability of the Cosmos SDK.types/msgservice/msg_service.go (2)
- 17-17: The import of
cosmossdk.io/core/registryis consistent with the PR's goal to abstract the interaction with theInterfaceRegistry, promoting a loosely coupled architecture.- 25-25: Updating the
RegisterMsgServiceDescfunction to acceptregistry.LegacyRegistryas its parameter is a strategic move towards decoupling and abstracting the interface registration process. This change is in line with the PR's objectives and enhances the SDK's modularity.x/staking/types/codec.go (2)
- 4-4: The addition of
cosmossdk.io/core/registryto the imports supports the PR's aim of reducing direct dependencies on the SDK by abstracting the interface registration process.- 32-32: Modifying the
RegisterInterfacesfunction to useregistry.LegacyRegistryaligns with the objective of enhancing the SDK's modularity and maintainability by abstracting away direct dependencies.x/auth/vesting/types/codec.go (2)
- 4-4: Importing
cosmossdk.io/core/registryis a strategic move towards decoupling the module from direct SDK dependencies, aligning with the PR's objectives to enhance modularity.- 30-30: The update to the
RegisterInterfacesfunction to utilizeregistry.LegacyRegistryis a positive step towards abstracting the interface registration process, which is in line with the PR's goal of reducing direct dependencies on the SDK.x/consensus/module.go (2)
- 10-10: The import of
cosmossdk.io/core/registrysupports the PR's aim of abstracting the interaction with theInterfaceRegistry, which is a key step towards achieving a more modular and maintainable architecture.- 64-64: Updating the
RegisterInterfacesfunction to useregistry.LegacyRegistryaligns with the PR's objectives of decoupling modules from direct SDK dependencies, thereby enhancing modularity.x/accounts/module.go (2)
- 7-7: The addition of
cosmossdk.io/core/registryto the imports is consistent with the PR's goal of abstracting the interface registration process, which contributes to the SDK's modularity and maintainability.- 55-55: Modifying the
RegisterInterfacesfunction to utilizeregistry.LegacyRegistryis a strategic move towards decoupling the module from direct SDK dependencies, aligning with the PR's objectives.x/group/codec.go (2)
- 4-4: The import of
cosmossdk.io/core/registryaligns with the PR's objective to abstract the interaction with theInterfaceRegistry, promoting a more loosely coupled architecture.- 37-37: Updating the
RegisterInterfacesfunction to useregistry.LegacyRegistrysupports the PR's goal of enhancing the SDK's modularity by reducing direct dependencies on specific SDK components.x/params/module.go (2)
- 10-10: The import of
cosmossdk.io/core/registryis a positive step towards achieving a more modular and maintainable architecture by abstracting the interface registration process.- 67-67: The change in the
RegisterInterfacesfunction to useregistry.LegacyRegistryaligns with the PR's objectives of decoupling modules from direct SDK dependencies, thereby enhancing modularity.x/accounts/utils_test.go (2)
- 46-46: Updating the
RegisterInterfacefunction in theinterfaceRegistrystruct to useprotoiface.MessageV1aligns with the broader goal of abstracting interface registration and ensuring compatibility with the updated interface definitions.- 48-48: The modification of the
RegisterImplementationsfunction to useprotoiface.MessageV1is a necessary update to maintain compatibility with the new interface definitions, supporting the PR's objectives of enhancing modularity.x/genutil/module.go (2)
- 8-8: The import of
cosmossdk.io/core/registrysupports the PR's aim of abstracting the interaction with theInterfaceRegistry, which is a key step towards achieving a more modular and maintainable architecture.- 101-101: The update to the
RegisterInterfacesmethod to useregistry.LegacyRegistryaligns with the PR's objectives of decoupling modules from direct SDK dependencies, thereby enhancing modularity.core/appmodule/v2/appmodule.go (2)
- 6-6: The import of
"cosmossdk.io/core/registry"is correctly added to support the new interfaceHasRegisterInterfaces. This aligns with the PR's objective to decouplex/modulefrom direct SDK dependencies.- 95-98: The introduction of the
HasRegisterInterfacesinterface with theRegisterInterfacesmethod accepting aregistry.LegacyRegistryparameter is a strategic move towards decoupling modules from direct SDK dependencies. This change promotes modularity and maintainability by abstracting the interaction with theInterfaceRegistry.x/circuit/module.go (2)
- 13-13: The addition of the
"cosmossdk.io/core/registry"import is necessary for utilizing theregistry.LegacyRegistryin theRegisterInterfacesmethod. This change supports the PR's goal of reducing direct dependencies on the SDK.- 56-56: The modification of the
RegisterInterfacesfunction to accept aregistry.LegacyRegistryparameter instead of acodectypes.InterfaceRegistryis in line with the PR's objective to abstract the interaction with theInterfaceRegistry. This change enhances modularity by using a more generic interface.core/appmodule/module.go (2)
- 9-9: The change in the import statement from
appmodule "cosmossdk.io/core/appmodule/v2"to"cosmossdk.io/core/appmodule/v2"is a minor adjustment that does not affect functionality but aligns with Go conventions for package naming and imports.- 73-75: The addition of the
HasRegisterInterfacestype alias, pointing toappmodule.HasRegisterInterfaces, is a good practice for exposing interfaces in a more accessible manner. This change facilitates easier usage of the interface across different modules.x/protocolpool/module.go (2)
- 12-12: The addition of the
"cosmossdk.io/core/registry"import is necessary for the updatedRegisterInterfacesmethod to useregistry.LegacyRegistry. This aligns with the PR's goal of abstracting direct dependencies on the SDK.- 74-74: Updating the
RegisterInterfacesmethod to acceptregistry.LegacyRegistryinstead ofcodectypes.InterfaceRegistryis a strategic move towards decoupling and promoting a more modular architecture. This change is consistent with the PR's objectives.x/nft/module/module.go (2)
- 11-11: The addition of the
"cosmossdk.io/core/registry"import is correctly implemented to facilitate the use ofregistry.LegacyRegistryin theRegisterInterfacesmethod. This change supports the PR's goal of reducing direct SDK dependencies.- 74-74: Modifying the
RegisterInterfacesfunction to useregistry.LegacyRegistryinstead ofcdctypes.InterfaceRegistryaligns with the PR's objective of abstracting the interaction with theInterfaceRegistry. This enhances the modularity of the module.x/feegrant/module/module.go (2)
- 13-13: The addition of the
"cosmossdk.io/core/registry"import is necessary for the updatedRegisterInterfacesmethod to useregistry.LegacyRegistry. This aligns with the PR's goal of abstracting direct dependencies on the SDK.- 74-74: Updating the
RegisterInterfacesmethod to acceptregistry.LegacyRegistryinstead ofcodectypes.InterfaceRegistryis a strategic move towards decoupling and promoting a more modular architecture. This change is consistent with the PR's objectives.x/upgrade/module.go (2)
- 13-13: The addition of the
"cosmossdk.io/core/registry"import is correctly implemented to facilitate the use ofregistry.LegacyRegistryin theRegisterInterfacesmethod. This change supports the PR's goal of reducing direct SDK dependencies.- 81-81: Modifying the
RegisterInterfacesfunction to useregistry.LegacyRegistryinstead ofcodectypes.InterfaceRegistryaligns with the PR's objective of abstracting the interaction with theInterfaceRegistry. This enhances the modularity of the module.x/crisis/module.go (3)
- 13-13: The addition of
"cosmossdk.io/core/registry"is aligned with the PR's goal to enhance modularity by abstracting the interaction withInterfaceRegistry. Good job on maintaining clean and organized import statements.- 29-29: Implementing
appmodule.HasRegisterInterfacesinAppModuleis a strategic move towards standardizing module message type registration. This aligns well with the PR's objectives.- 77-77: Changing the parameter type in
RegisterInterfacestoregistry.LegacyRegistryis a key step in reducing direct dependencies on SDK components, fostering a more modular architecture. This change is well-aligned with the PR's objectives.x/evidence/module.go (3)
- 13-13: The addition of
"cosmossdk.io/core/registry"supports the PR's goal of abstracting interactions withInterfaceRegistry, contributing to the modularity of the SDK. Well done.- 30-30: Implementing
appmodule.HasRegisterInterfacesinAppModulealigns with the efforts to standardize and abstract module message type registration. This is a positive step towards the PR's goals.- 85-85: Modifying the
RegisterInterfacesfunction to useregistry.LegacyRegistryis an important step towards minimizing direct SDK dependencies, aligning perfectly with the PR's objectives for a modular architecture.types/module/core_module.go (2)
- 13-13: Adding
"cosmossdk.io/core/registry"is consistent with the PR's goal of abstractingInterfaceRegistryinteractions, which is a positive step towards enhancing the SDK's modularity.- 174-174: The modification of the
RegisterInterfacesfunction to utilizeregistry.LegacyRegistryis crucial for reducing direct SDK dependencies, aligning with the PR's objectives towards a more modular architecture.x/authz/module/module.go (3)
- 13-13: The import of
"cosmossdk.io/core/registry"aligns with the PR's objective to decouplex/modulefrom the SDK by using a more streamlined interface for interacting with theInterfaceRegistry. This change is consistent with the goal of enhancing modularity.- 30-35: The implementation of interfaces for
AppModulehas been updated to includeappmodule.HasRegisterInterfaces. This change is crucial for ensuring that theAppModuleconforms to the new interface structure introduced in the core package, facilitating a more abstracted interaction with theInterfaceRegistry.- 95-95: The modification of the
RegisterInterfacesfunction to useregistry.LegacyRegistryinstead ofcdctypes.InterfaceRegistryis a key part of the refactoring effort. This change supports the broader goal of reducing direct dependencies on specific SDK components, thereby promoting a more loosely coupled architecture.x/auth/module.go (2)
- 8-8: The addition of the
"cosmossdk.io/core/registry"import is consistent with the PR's objective to refactor the Cosmos SDK for enhanced modularity by abstracting the interaction with theInterfaceRegistry. This change is appropriate and aligns with the overall goal of the PR.- 74-74: Changing the
RegisterInterfacesfunction to acceptregistry.LegacyRegistryas its parameter instead ofcdctypes.InterfaceRegistryis a crucial step towards decoupling the module from direct SDK dependencies. This modification supports the PR's objective of promoting a more loosely coupled architecture.x/group/module/module.go (3)
- 13-13: Importing
"cosmossdk.io/core/registry"is in line with the PR's goal to refactor the Cosmos SDK for better modularity by abstracting the interaction with theInterfaceRegistry. This change is appropriate and supports the overarching objective of the PR.- 31-37: The implementation of interfaces for
AppModule, includingappmodule.HasRegisterInterfaces, ensures that the module conforms to the new interface structure. This is essential for facilitating a more abstracted interaction with theInterfaceRegistry, aligning with the PR's goal of reducing direct dependencies on SDK components.- 86-86: Modifying the
RegisterInterfacesfunction to useregistry.LegacyRegistryinstead ofcdctypes.InterfaceRegistryis a critical part of the refactoring effort. This change promotes a more loosely coupled architecture by reducing direct dependencies on specific SDK components.x/staking/module.go (2)
- 14-14: The addition of the
"cosmossdk.io/core/registry"import aligns with the PR's objective to enhance modularity in the Cosmos SDK by abstracting the interaction with theInterfaceRegistry. This change is consistent with the goal of promoting a more loosely coupled architecture.- 85-85: Changing the
RegisterInterfacesfunction to acceptregistry.LegacyRegistryas its parameter instead ofcdctypes.InterfaceRegistryis a key step towards decoupling the module from direct SDK dependencies. This modification supports the PR's objective of fostering a more modular and flexible architecture.x/mint/module.go (3)
- 12-12: Importing
"cosmossdk.io/core/registry"is consistent with the PR's objective to refactor the Cosmos SDK for better modularity by abstracting the interaction with theInterfaceRegistry. This change supports the overarching goal of the PR and is appropriate.- 27-32: The implementation of interfaces for
AppModule, includingappmodule.HasRegisterInterfaces, ensures the module conforms to the new interface structure. This is crucial for facilitating a more abstracted interaction with theInterfaceRegistry, aligning with the PR's goal of reducing direct dependencies on SDK components.- 85-85: Modifying the
RegisterInterfacesfunction to useregistry.LegacyRegistryinstead ofcdctypes.InterfaceRegistryis an essential part of the refactoring effort. This change promotes a more loosely coupled architecture by reducing direct dependencies on specific SDK components.x/bank/module.go (2)
- 14-14: The addition of
"cosmossdk.io/core/registry"import aligns with the PR's objective to decouplex/modulefrom the SDK by using a more abstracted interaction with theInterfaceRegistry. This change is necessary for the refactoring effort and correctly introduces theregistrypackage for use in theRegisterInterfacesmethod.- 85-85: The modification of the
RegisterInterfacesfunction's parameter type fromcodectypes.InterfaceRegistrytoregistry.LegacyRegistryis a key part of the refactoring effort to reduce direct dependencies on specific SDK components. This change promotes a more loosely coupled architecture by abstracting the way modules interact with theInterfaceRegistry. Ensure that all implementations ofRegisterInterfacesacross different modules are updated to use the newregistry.LegacyRegistryinterface for consistency.x/slashing/module.go (2)
- 12-12: The addition of the
"cosmossdk.io/core/registry"import is consistent with the overarching goal of the PR to abstract the interaction with theInterfaceRegistryand reduce direct dependencies on the SDK. This change is necessary for the refactoring and correctly introduces theregistrypackage for use in theRegisterInterfacesmethod.- 85-85: Changing the
RegisterInterfacesfunction's parameter type fromcodectypes.InterfaceRegistrytoregistry.LegacyRegistryis crucial for achieving the PR's objective of decoupling modules from direct SDK dependencies. This modification supports a more modular architecture by abstracting the interface registration process. Ensure that all modules implementingRegisterInterfacesare updated accordingly to maintain consistency across the SDK.x/distribution/module.go (2)
- 13-13: The import of
"cosmossdk.io/core/registry"is aligned with the PR's goal to abstract the interaction with theInterfaceRegistry. This change is part of the effort to reduce the direct dependency on the SDK, facilitating a more modular architecture. Correctly introduces theregistrypackage for use in theRegisterInterfacesmethod.- 95-95: Modifying the
RegisterInterfacesfunction's parameter type toregistry.LegacyRegistryis a significant step towards decoupling the module from direct SDK dependencies. This change promotes a more loosely coupled architecture by abstracting the interface registration process. It's important to ensure consistency in the implementation ofRegisterInterfacesacross all modules within the SDK.x/gov/module.go (2)
- 13-13: Adding the
"cosmossdk.io/core/registry"import supports the PR's objective to abstract the interaction with theInterfaceRegistry, reducing the direct dependency on the SDK. This change is part of the broader effort to enhance modularity within the SDK by introducing theregistrypackage for use in theRegisterInterfacesmethod.- 113-113: The change in the
RegisterInterfacesfunction's parameter type toregistry.LegacyRegistryis crucial for the PR's goal of decoupling modules from the SDK. This modification supports a more modular architecture by abstracting the interface registration process. Consistency in the implementation ofRegisterInterfacesacross all modules is essential for the SDK's modularity.codec/types/interface_registry.go (5)
- 10-10: The addition of the
protoifaceimport is necessary for the changes introduced in this PR, specifically for the usage ofprotoiface.MessageV1. This aligns well with the PR's objectives.- 12-12: The addition of the
registryimport is essential for embedding theLegacyRegistrytype in theInterfaceRegistry. This change supports the PR's goal of enhancing modularity and maintainability within the Cosmos SDK.- 39-39: Embedding the
LegacyRegistrytype from theregistrypackage into theInterfaceRegistryis a positive change that contributes to the decoupling efforts and aligns with the broader architectural goals of the Cosmos SDK.- 147-147: The replacement of
proto.Messagewithprotoiface.MessageV1in theRegisterInterfacemethod aligns with the PR's objectives of enhancing modularity and maintainability by promoting a more generic interface for message handling.- 177-177: Similarly, the replacement of
proto.Messagewithprotoiface.MessageV1in theRegisterImplementationsmethod supports the PR's goal of reducing direct dependencies on specific SDK components, furthering the efforts towards a more loosely coupled architecture.x/accounts/keeper.go (2)
- 13-13: The addition of the import
google.golang.org/protobuf/runtime/protoifacealigns with the PR's objective to refactor the usage ofInterfaceRegistrymethods, transitioning fromgogoproto.Messagetoprotoiface.MessageV1. This change is necessary for the new method signatures and supports the goal of reducing direct dependencies on specific SDK components.- 60-61: The update of method signatures in the
InterfaceRegistryinterface fromgogoproto.Messagetoprotoiface.MessageV1is a key part of the PR's objective. This change enhances modularity by using a more generic interface for message handling,protoiface.MessageV1, instead of the specificgogoproto.Message. It's crucial to ensure that all implementations of these methods across the SDK are updated accordingly to maintain compatibility and functionality.types/module/module_test.go (3)
- 10-10: The import statement for
appmodulev2has been added, and it's clear that this change is part of the effort to decouplex/modulefrom direct dependencies on the SDK, specifically moving away fromabci.ValidatorUpdatetoappmodulev2.ValidatorUpdate. This aligns with the PR's objective to enhance modularity and maintainability by using more abstracted interfaces.- 274-274: The change from
abci.ValidatorUpdatetoappmodulev2.ValidatorUpdatein theEndBlockmethod call is consistent with the PR's goal of reducing direct dependencies on specific SDK components. However, it's crucial to ensure that theappmodulev2.ValidatorUpdatetype is fully compatible and provides all necessary fields and methods used in the context of theEndBlockmethod. This change should be carefully tested to avoid any unintended side effects.- 281-282: The update to use
appmodulev2.ValidatorUpdatein anotherEndBlockmethod call further emphasizes the shift towards using more abstracted interfaces. As with the previous change, it's important to ensure compatibility and test thoroughly. Given that this change is part of a broader effort to refactor and improve the architecture, it's a positive step towards the project's goals.testutil/mock/types_module_module.go (4)
- 72-72: The change from
types0.InterfaceRegistrytoregistry.LegacyRegistryin theRegisterInterfacesmethod ofMockAppModuleBasicaligns with the PR's objective to decouplex/modulefrom direct SDK dependencies. This modification enhances modularity by using a more abstract interface.- 157-157: Similarly, the update in the
RegisterInterfacesmethod ofMockAppModuleto useregistry.LegacyRegistrysupports the overarching goal of reducing direct dependencies on the SDK's core types. This change is consistent with the efforts to promote a loosely coupled architecture.- 329-329: The adjustment in the
RegisterInterfacesmethod ofMockHasRegisterInterfacesto utilizeregistry.LegacyRegistryis another example of the PR's commitment to enhancing the SDK's modularity. By abstracting the interaction with theInterfaceRegistry, this change contributes to the broader architectural improvements.- 743-743: The modification in the
RegisterInterfacesmethod ofMockHasABCIEndBlockto employregistry.LegacyRegistryis consistent with the PR's objective of minimizing direct dependencies on specific SDK components. This change further exemplifies the move towards a more flexible and maintainable codebase.types/module/module.go (3)
- 49-49: The change to use
appmodule.HasRegisterInterfacesin theAppModuleBasicinterface aligns with the PR's objective to decouplex/modulefrom direct SDK dependencies. This modification promotes modularity by leveraging a more abstracted interface.- 61-61: Similarly, updating the
AppModuleinterface to useappmodule.HasRegisterInterfacessupports the goal of reducing direct dependencies on the SDK. This change is consistent with the approach taken in theAppModuleBasicinterface and further enhances the modularity of the system.- 315-317: The modification of the
RegisterInterfacesmethod to acceptregistry.LegacyRegistryinstead oftypes.InterfaceRegistryis a crucial part of the PR's objective to remove the dependency onSDK/types/codec. This change facilitates a more generic way of handling interface registration, which is in line with the goal of promoting a loosely coupled architecture. It's important to ensure that all modules implementingappmodule.HasRegisterInterfacesare updated accordingly to avoid integration issues.Verification successful
The verification process confirms that the
RegisterInterfacesmethod has been successfully updated to acceptregistry.LegacyRegistryin the interfaceHasRegisterInterfacesand its implementations, aligning with the PR's objective to remove the dependency onSDK/types/codecand promote a loosely coupled architecture. This ensures that all modules implementingappmodule.HasRegisterInterfacesare updated accordingly, avoiding integration issues.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that all modules implementing appmodule.HasRegisterInterfaces have been updated to use registry.LegacyRegistry. ast-grep --lang go --pattern $'type $_ struct { $$$ RegisterInterfaces(registry.LegacyRegistry) { $$$ } $$$ }'Length of output: 636
Script:
#!/bin/bash # Corrected script to verify that interfaces implementing appmodule.HasRegisterInterfaces have been updated to use registry.LegacyRegistry. ast-grep --lang go --pattern $'interface { RegisterInterfaces(registry.LegacyRegistry) }'Length of output: 481
testutil/mock/types_mock_appmodule.go (2)
- 153-153: The change from
types0.InterfaceRegistrytoregistry.LegacyRegistryin theRegisterInterfacesmethod forMockAppModuleWithAllExtensionsaligns with the PR's objective to decouplex/modulefrom direct SDK dependencies. This modification supports the broader goal of enhancing modularity by utilizing a more abstracted interface for registry operations.- 335-335: Similarly, the update in
MockAppModuleWithAllExtensionsABCIto useregistry.LegacyRegistryinstead oftypes0.InterfaceRegistryin itsRegisterInterfacesmethod is consistent with the overarching aim of reducing direct dependencies on the SDK's core types. This change facilitates a more flexible and loosely coupled architecture, which is beneficial for the maintainability and scalability of the Cosmos SDK.
julienrbrt
approved these changes
Mar 5, 2024
| @@ -82,11 +82,6 @@ type HasAminoCodec interface { | |||
| RegisterLegacyAminoCodec(*codec.LegacyAmino) | |||
| } | |||
|
|
|||
| // HasRegisterInterfaces is the interface for modules to register their msg types. | |||
There was a problem hiding this comment.
Can we get a small changelog for that?
| @@ -18,7 +19,7 @@ func RegisterLegacyAminoCodec(cdc *codec.LegacyAmino) { | |||
| } | |||
|
|
|||
| // RegisterInterfaces registers the interfaces types with the Interface Registry. | |||
| func RegisterInterfaces(registry types.InterfaceRegistry) { | |||
| func RegisterInterfaces(registry registry.LegacyRegistry) { | |||
There was a problem hiding this comment.
ditto, can we have a mention of this in upgrading.md under modules > core api?
tac0turtle
reviewed
Mar 5, 2024
| _ module.HasName = AppModule{} | ||
| _ module.HasAminoCodec = AppModule{} | ||
| _ module.HasGRPCGateway = AppModule{} | ||
| _ module.HasRegisterInterfaces = AppModule{} |
There was a problem hiding this comment.
should we alias this in module?
There was a problem hiding this comment.
Aliasing it back in module would be good for limiting breaking changes.
12 tasks
There was a problem hiding this comment.
Review Status
Actionable comments generated: 1
Configuration used: .coderabbit.yml
Files selected for processing (2)
- CHANGELOG.md (1 hunks)
- UPGRADING.md (1 hunks)
Additional comments: 1
UPGRADING.md (1)
- 164-169: The change to the
RegisterInterfacesmethod signature in theAppModulestruct is a critical update for developers working with the Cosmos SDK. This modification aligns with the broader objective of enhancing the SDK's modularity and maintainability by abstracting the interaction with theInterfaceRegistry. It's essential for module developers to update their implementations accordingly to ensure compatibility with the new architecture. This change promotes a more flexible and loosely coupled design, which is beneficial for the long-term evolution of the Cosmos SDK ecosystem.
12 tasks
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: .coderabbit.yml
Files selected for processing (6)
- CHANGELOG.md (1 hunks)
- UPGRADING.md (1 hunks)
- codec/types/interface_registry.go (4 hunks)
- x/accounts/module.go (2 hunks)
- x/auth/module.go (2 hunks)
- x/genutil/module.go (2 hunks)
Files skipped from review as they are similar to previous changes (6)
- CHANGELOG.md
- UPGRADING.md
- codec/types/interface_registry.go
- x/accounts/module.go
- x/auth/module.go
- x/genutil/module.go
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
High level Goal: Remove dependency of x/module -> SDK.
This PR's goal: Remove dependency on SDK/types/codec through interface registry.
Methodology: Interact with InterfaceRegistry through a thinner interface defined in core.
Spun out of work in #19641
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...
!in the type prefix if API or client breaking changeCHANGELOG.mdReviewers 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...
Summary by CodeRabbit
HasRegisterInterfacesinterface for more streamlined module message type registration.