Skip to content
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

refactor: remove dependency x/module -> sdk through InterfaceRegistry #19652

Merged
merged 7 commits into from
Mar 6, 2024

Conversation

kocubinski
Copy link
Member

@kocubinski kocubinski commented Mar 5, 2024

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...

  • included the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • reviewed "Files changed" and left comments if necessary
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • updated the relevant documentation or specification, including comments for documenting Go code
  • 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 in the PR title
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic, API design and naming, documentation is accurate, tests and test coverage

Summary by CodeRabbit

  • Refactor
    • Enhanced interface registration across various modules to improve system interoperability and maintainability.
  • New Features
    • Introduced HasRegisterInterfaces interface for more streamlined module message type registration.
  • Chores
    • Updated import paths and interface usage to align with the latest coding standards and dependencies.

- 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
@kocubinski kocubinski requested a review from a team as a code owner March 5, 2024 16:22
@kocubinski kocubinski changed the title refactor: remove dependency x/module -> sdk in InterfaceRegistry refactor: remove dependency x/module -> sdk through InterfaceRegistry Mar 5, 2024
Copy link
Contributor

coderabbitai bot commented Mar 5, 2024

Walkthrough

Walkthrough

This update signifies a significant overhaul in how interfaces and message types are registered within the Cosmos SDK. By transitioning to protoiface.MessageV1 from proto.Message and introducing a LegacyRegistry, the changes aim to streamline protobuf information registration. The introduction of the HasRegisterInterfaces interface across various modules enhances the registration process, aligning with modern practices and potentially setting the stage for future protocol upgrades and enhancements.

Changes

Files Change Summary
codec/types/interface_registry.go, core/appmodule/module.go, x/.../keeper.go Replaced proto.Message with protoiface.MessageV1; added protoiface import. Introduced HasRegisterInterfaces interface.
core/registry/legacy.go, testutil/mock/types_mock_appmodule.go, types/module/module.go Defined LegacyRegistry interface for registration. Replaced types0.InterfaceRegistry with registry.LegacyRegistry.
x/.../module.go, x/.../types/codec.go Updated imports and method parameters for interface registration.
x/.../module/module.go, x/.../types/codec.go Imported registry from new path; modified RegisterInterfaces parameter type.

Related issues

  • v2 protobuf Registry #10978: The changes seem to align with the issue's objectives by improving the method of registering protobuf information, utilizing declarative specifications, and potentially paving the way for storing pinned file descriptors. The introduction of LegacyRegistry and adjustments in protobuf type handling could serve as foundational steps towards addressing some of the outlined enhancements.

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?

Share

Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit-tests for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit tests for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit tests.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • The JSON schema for the configuration file is available here.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: .coderabbit.yml

Commits Files that changed from the base of the PR and between e8c9cd2 and f127cd4.
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 previous types.InterfaceRegistry. This aligns with the PR's objective to decouple x/module from direct SDK dependencies.
  • 10-10: The RegisterInterfaces function signature has been updated to use registry.LegacyRegistry as its parameter type. This change is consistent with the PR's goal of enhancing modularity by abstracting the interaction with the InterfaceRegistry. Ensure that all implementations of this interface across the SDK are updated accordingly to maintain compatibility.
Verification successful

The verification process confirms that the RegisterInterfaces function signature has been updated to use registry.LegacyRegistry as 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 the InterfaceRegistry. 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 RegisterInterfaces function now correctly uses registry.LegacyRegistry as its parameter type, which is part of the effort to abstract the interaction with the InterfaceRegistry. This change should be consistently applied across all modules to ensure compatibility.
Verification successful

The verification process confirms that the RegisterInterfaces function consistently uses registry.LegacyRegistry as its parameter type across various modules in the codebase. This aligns with the effort to abstract the interaction with the InterfaceRegistry and 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 RegisterInterfaces function signature has been modified to use registry.LegacyRegistry, aligning with the objective to abstract the interaction with the InterfaceRegistry. This is a positive change towards achieving a more loosely coupled architecture.
Verification successful

The verification process confirms that the RegisterInterfaces function signature, utilizing registry.LegacyRegistry, has been consistently applied across various modules within the SDK. This aligns with the objective of abstracting the interaction with the InterfaceRegistry and 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 RegisterInterfaces function now uses registry.LegacyRegistry as its parameter type, which is part of the broader effort to abstract the interaction with the InterfaceRegistry. This change is crucial for achieving a more modular architecture.
Verification successful

The verification process confirms that the RegisterInterfaces function now uses registry.LegacyRegistry as its parameter type across various implementations within the codebase. This change aligns with the effort to abstract the interaction with the InterfaceRegistry for 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 RegisterInterfaces function signature has been modified to use registry.LegacyRegistry, which is in line with the goal of abstracting the interaction with the InterfaceRegistry. This change supports the objective of achieving a more loosely coupled architecture.
Verification successful

The verification process confirms that the RegisterInterfaces function signature, utilizing registry.LegacyRegistry, has been consistently applied across various modules within the SDK. This change aligns with the objective of abstracting the interaction with the InterfaceRegistry and 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 RegisterInterfaces function signature has been modified to use registry.LegacyRegistry, aligning with the objective to abstract the interaction with the InterfaceRegistry. This change is a positive step towards achieving a more modular architecture.
Verification successful

The verification process confirms that the RegisterInterfaces function signature, utilizing registry.LegacyRegistry, has been consistently applied across various modules within the SDK. This change aligns with the objective of abstracting the interaction with the InterfaceRegistry and 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 RegisterInterfaces function now uses registry.LegacyRegistry as its parameter type, which is part of the broader effort to abstract the interaction with the InterfaceRegistry. This change is crucial for achieving a more modular architecture.
Verification successful

The verification process confirms that the RegisterInterfaces function now uses registry.LegacyRegistry as its parameter type across various implementations within the codebase. This aligns with the effort to abstract the interaction with the InterfaceRegistry for 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 RegisterInterfaces function now correctly uses registry.LegacyRegistry as its parameter type, which is part of the effort to abstract the interaction with the InterfaceRegistry. This change is crucial for achieving a more modular architecture.
Verification successful

The verification process confirms that all RegisterInterfaces implementations across various modules have been updated to use registry.LegacyRegistry as their parameter type, aligning with the efforts to abstract the interaction with the InterfaceRegistry for 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 RegisterInterfaces function signature has been modified to use registry.LegacyRegistry, which is in line with the goal of abstracting the interaction with the InterfaceRegistry. This change supports the objective of achieving a more loosely coupled architecture.
Verification successful

The verification process confirms that the RegisterInterfaces function signature, utilizing registry.LegacyRegistry, has been consistently applied across the SDK. This aligns with the goal of abstracting the interaction with the InterfaceRegistry and 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 LegacyRegistry interface 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 the InterfaceRegistry, 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 decouple x/module from direct SDK dependencies. This change is consistent with the goal of enhancing modularity.
  • 22-22: The change in the parameter type of the RegisterInterfaces function from types.InterfaceRegistry to registry.LegacyRegistry is 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 the InterfaceRegistry. This change facilitates a more loosely coupled architecture.
  • 22-22: Updating the parameter type in the RegisterInterfaces function to registry.LegacyRegistry aligns 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 RegisterInterfaces function to registry.LegacyRegistry is 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 the InterfaceRegistry. 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 RegisterInterfaces function to registry.LegacyRegistry supports 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 the InterfaceRegistry. 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 RegisterInterfaces function to registry.LegacyRegistry aligns 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 the InterfaceRegistry. This change is consistent with the effort to reduce direct dependencies on the SDK, enhancing modularity.
  • 15-16: The implementation of appmodule.HasRegisterInterfaces instead of module.HasRegisterInterfaces is 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 RegisterInterfaces function to registry.LegacyRegistry is 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 the InterfaceRegistry. 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 RegisterInterfaces function to registry.LegacyRegistry supports 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 the InterfaceRegistry. 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 RegisterInterfaces function to registry.LegacyRegistry aligns 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 the InterfaceRegistry. 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 RegisterInterfaces function to registry.LegacyRegistry aligns 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 the InterfaceRegistry. 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 RegisterInterfaces function to registry.LegacyRegistry supports 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/registry aligns with the PR's objective to decouple x/module from direct SDK dependencies by utilizing a more abstracted interaction with the InterfaceRegistry.
  • 31-31: The change in the RegisterInterfaces function to use registry.LegacyRegistry instead 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/registry is consistent with the PR's goal to abstract the interaction with the InterfaceRegistry, promoting a loosely coupled architecture.
  • 25-25: Updating the RegisterMsgServiceDesc function to accept registry.LegacyRegistry as 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/registry to the imports supports the PR's aim of reducing direct dependencies on the SDK by abstracting the interface registration process.
  • 32-32: Modifying the RegisterInterfaces function to use registry.LegacyRegistry aligns 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/registry is 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 RegisterInterfaces function to utilize registry.LegacyRegistry is 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/registry supports the PR's aim of abstracting the interaction with the InterfaceRegistry, which is a key step towards achieving a more modular and maintainable architecture.
  • 64-64: Updating the RegisterInterfaces function to use registry.LegacyRegistry aligns 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/registry to 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 RegisterInterfaces function to utilize registry.LegacyRegistry is 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/registry aligns with the PR's objective to abstract the interaction with the InterfaceRegistry, promoting a more loosely coupled architecture.
  • 37-37: Updating the RegisterInterfaces function to use registry.LegacyRegistry supports 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/registry is a positive step towards achieving a more modular and maintainable architecture by abstracting the interface registration process.
  • 67-67: The change in the RegisterInterfaces function to use registry.LegacyRegistry aligns 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 RegisterInterface function in the interfaceRegistry struct to use protoiface.MessageV1 aligns with the broader goal of abstracting interface registration and ensuring compatibility with the updated interface definitions.
  • 48-48: The modification of the RegisterImplementations function to use protoiface.MessageV1 is 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/registry supports the PR's aim of abstracting the interaction with the InterfaceRegistry, which is a key step towards achieving a more modular and maintainable architecture.
  • 101-101: The update to the RegisterInterfaces method to use registry.LegacyRegistry aligns 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 interface HasRegisterInterfaces. This aligns with the PR's objective to decouple x/module from direct SDK dependencies.
  • 95-98: The introduction of the HasRegisterInterfaces interface with the RegisterInterfaces method accepting a registry.LegacyRegistry parameter is a strategic move towards decoupling modules from direct SDK dependencies. This change promotes modularity and maintainability by abstracting the interaction with the InterfaceRegistry.
x/circuit/module.go (2)
  • 13-13: The addition of the "cosmossdk.io/core/registry" import is necessary for utilizing the registry.LegacyRegistry in the RegisterInterfaces method. This change supports the PR's goal of reducing direct dependencies on the SDK.
  • 56-56: The modification of the RegisterInterfaces function to accept a registry.LegacyRegistry parameter instead of a codectypes.InterfaceRegistry is in line with the PR's objective to abstract the interaction with the InterfaceRegistry. 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 HasRegisterInterfaces type alias, pointing to appmodule.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 updated RegisterInterfaces method to use registry.LegacyRegistry. This aligns with the PR's goal of abstracting direct dependencies on the SDK.
  • 74-74: Updating the RegisterInterfaces method to accept registry.LegacyRegistry instead of codectypes.InterfaceRegistry is 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 of registry.LegacyRegistry in the RegisterInterfaces method. This change supports the PR's goal of reducing direct SDK dependencies.
  • 74-74: Modifying the RegisterInterfaces function to use registry.LegacyRegistry instead of cdctypes.InterfaceRegistry aligns with the PR's objective of abstracting the interaction with the InterfaceRegistry. 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 updated RegisterInterfaces method to use registry.LegacyRegistry. This aligns with the PR's goal of abstracting direct dependencies on the SDK.
  • 74-74: Updating the RegisterInterfaces method to accept registry.LegacyRegistry instead of codectypes.InterfaceRegistry is 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 of registry.LegacyRegistry in the RegisterInterfaces method. This change supports the PR's goal of reducing direct SDK dependencies.
  • 81-81: Modifying the RegisterInterfaces function to use registry.LegacyRegistry instead of codectypes.InterfaceRegistry aligns with the PR's objective of abstracting the interaction with the InterfaceRegistry. 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 with InterfaceRegistry. Good job on maintaining clean and organized import statements.
  • 29-29: Implementing appmodule.HasRegisterInterfaces in AppModule is a strategic move towards standardizing module message type registration. This aligns well with the PR's objectives.
  • 77-77: Changing the parameter type in RegisterInterfaces to registry.LegacyRegistry is 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 with InterfaceRegistry, contributing to the modularity of the SDK. Well done.
  • 30-30: Implementing appmodule.HasRegisterInterfaces in AppModule aligns 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 RegisterInterfaces function to use registry.LegacyRegistry is 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 abstracting InterfaceRegistry interactions, which is a positive step towards enhancing the SDK's modularity.
  • 174-174: The modification of the RegisterInterfaces function to utilize registry.LegacyRegistry is 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 decouple x/module from the SDK by using a more streamlined interface for interacting with the InterfaceRegistry. This change is consistent with the goal of enhancing modularity.
  • 30-35: The implementation of interfaces for AppModule has been updated to include appmodule.HasRegisterInterfaces. This change is crucial for ensuring that the AppModule conforms to the new interface structure introduced in the core package, facilitating a more abstracted interaction with the InterfaceRegistry.
  • 95-95: The modification of the RegisterInterfaces function to use registry.LegacyRegistry instead of cdctypes.InterfaceRegistry is 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 the InterfaceRegistry. This change is appropriate and aligns with the overall goal of the PR.
  • 74-74: Changing the RegisterInterfaces function to accept registry.LegacyRegistry as its parameter instead of cdctypes.InterfaceRegistry is 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 the InterfaceRegistry. This change is appropriate and supports the overarching objective of the PR.
  • 31-37: The implementation of interfaces for AppModule, including appmodule.HasRegisterInterfaces, ensures that the module conforms to the new interface structure. This is essential for facilitating a more abstracted interaction with the InterfaceRegistry, aligning with the PR's goal of reducing direct dependencies on SDK components.
  • 86-86: Modifying the RegisterInterfaces function to use registry.LegacyRegistry instead of cdctypes.InterfaceRegistry is 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 the InterfaceRegistry. This change is consistent with the goal of promoting a more loosely coupled architecture.
  • 85-85: Changing the RegisterInterfaces function to accept registry.LegacyRegistry as its parameter instead of cdctypes.InterfaceRegistry is 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 the InterfaceRegistry. This change supports the overarching goal of the PR and is appropriate.
  • 27-32: The implementation of interfaces for AppModule, including appmodule.HasRegisterInterfaces, ensures the module conforms to the new interface structure. This is crucial for facilitating a more abstracted interaction with the InterfaceRegistry, aligning with the PR's goal of reducing direct dependencies on SDK components.
  • 85-85: Modifying the RegisterInterfaces function to use registry.LegacyRegistry instead of cdctypes.InterfaceRegistry is 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 decouple x/module from the SDK by using a more abstracted interaction with the InterfaceRegistry. This change is necessary for the refactoring effort and correctly introduces the registry package for use in the RegisterInterfaces method.
  • 85-85: The modification of the RegisterInterfaces function's parameter type from codectypes.InterfaceRegistry to registry.LegacyRegistry is 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 the InterfaceRegistry. Ensure that all implementations of RegisterInterfaces across different modules are updated to use the new registry.LegacyRegistry interface 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 the InterfaceRegistry and reduce direct dependencies on the SDK. This change is necessary for the refactoring and correctly introduces the registry package for use in the RegisterInterfaces method.
  • 85-85: Changing the RegisterInterfaces function's parameter type from codectypes.InterfaceRegistry to registry.LegacyRegistry is 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 implementing RegisterInterfaces are 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 the InterfaceRegistry. This change is part of the effort to reduce the direct dependency on the SDK, facilitating a more modular architecture. Correctly introduces the registry package for use in the RegisterInterfaces method.
  • 95-95: Modifying the RegisterInterfaces function's parameter type to registry.LegacyRegistry is 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 of RegisterInterfaces across 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 the InterfaceRegistry, reducing the direct dependency on the SDK. This change is part of the broader effort to enhance modularity within the SDK by introducing the registry package for use in the RegisterInterfaces method.
  • 113-113: The change in the RegisterInterfaces function's parameter type to registry.LegacyRegistry is 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 of RegisterInterfaces across all modules is essential for the SDK's modularity.
codec/types/interface_registry.go (5)
  • 10-10: The addition of the protoiface import is necessary for the changes introduced in this PR, specifically for the usage of protoiface.MessageV1. This aligns well with the PR's objectives.
  • 12-12: The addition of the registry import is essential for embedding the LegacyRegistry type in the InterfaceRegistry. This change supports the PR's goal of enhancing modularity and maintainability within the Cosmos SDK.
  • 39-39: Embedding the LegacyRegistry type from the registry package into the InterfaceRegistry is 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.Message with protoiface.MessageV1 in the RegisterInterface method 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.Message with protoiface.MessageV1 in the RegisterImplementations method 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/protoiface aligns with the PR's objective to refactor the usage of InterfaceRegistry methods, transitioning from gogoproto.Message to protoiface.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 InterfaceRegistry interface from gogoproto.Message to protoiface.MessageV1 is 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 specific gogoproto.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 appmodulev2 has been added, and it's clear that this change is part of the effort to decouple x/module from direct dependencies on the SDK, specifically moving away from abci.ValidatorUpdate to appmodulev2.ValidatorUpdate. This aligns with the PR's objective to enhance modularity and maintainability by using more abstracted interfaces.
  • 274-274: The change from abci.ValidatorUpdate to appmodulev2.ValidatorUpdate in the EndBlock method call is consistent with the PR's goal of reducing direct dependencies on specific SDK components. However, it's crucial to ensure that the appmodulev2.ValidatorUpdate type is fully compatible and provides all necessary fields and methods used in the context of the EndBlock method. This change should be carefully tested to avoid any unintended side effects.
  • 281-282: The update to use appmodulev2.ValidatorUpdate in another EndBlock method 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.InterfaceRegistry to registry.LegacyRegistry in the RegisterInterfaces method of MockAppModuleBasic aligns with the PR's objective to decouple x/module from direct SDK dependencies. This modification enhances modularity by using a more abstract interface.
  • 157-157: Similarly, the update in the RegisterInterfaces method of MockAppModule to use registry.LegacyRegistry supports 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 RegisterInterfaces method of MockHasRegisterInterfaces to utilize registry.LegacyRegistry is another example of the PR's commitment to enhancing the SDK's modularity. By abstracting the interaction with the InterfaceRegistry, this change contributes to the broader architectural improvements.
  • 743-743: The modification in the RegisterInterfaces method of MockHasABCIEndBlock to employ registry.LegacyRegistry is 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.HasRegisterInterfaces in the AppModuleBasic interface aligns with the PR's objective to decouple x/module from direct SDK dependencies. This modification promotes modularity by leveraging a more abstracted interface.
  • 61-61: Similarly, updating the AppModule interface to use appmodule.HasRegisterInterfaces supports the goal of reducing direct dependencies on the SDK. This change is consistent with the approach taken in the AppModuleBasic interface and further enhances the modularity of the system.
  • 315-317: The modification of the RegisterInterfaces method to accept registry.LegacyRegistry instead of types.InterfaceRegistry is a crucial part of the PR's objective to remove the dependency on SDK/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 implementing appmodule.HasRegisterInterfaces are updated accordingly to avoid integration issues.
Verification successful

The verification process confirms that the RegisterInterfaces method has been successfully updated to accept registry.LegacyRegistry in the interface HasRegisterInterfaces and its implementations, aligning with the PR's objective to remove the dependency on SDK/types/codec and promote a loosely coupled architecture. This ensures that all modules implementing appmodule.HasRegisterInterfaces are 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.InterfaceRegistry to registry.LegacyRegistry in the RegisterInterfaces method for MockAppModuleWithAllExtensions aligns with the PR's objective to decouple x/module from 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 MockAppModuleWithAllExtensionsABCI to use registry.LegacyRegistry instead of types0.InterfaceRegistry in its RegisterInterfaces method 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.

@@ -82,11 +82,6 @@ type HasAminoCodec interface {
RegisterLegacyAminoCodec(*codec.LegacyAmino)
}

// HasRegisterInterfaces is the interface for modules to register their msg types.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto, can we have a mention of this in upgrading.md under modules > core api?

_ module.HasName = AppModule{}
_ module.HasAminoCodec = AppModule{}
_ module.HasGRPCGateway = AppModule{}
_ module.HasRegisterInterfaces = AppModule{}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we alias this in module?

Copy link
Member

@julienrbrt julienrbrt Mar 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aliasing it back in module would be good for limiting breaking changes.

Copy link
Member

@tac0turtle tac0turtle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

love seeing this cleanup

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 1

Configuration used: .coderabbit.yml

Commits Files that changed from the base of the PR and between f127cd4 and 650c4c3.
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 RegisterInterfaces method signature in the AppModule struct 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 the InterfaceRegistry. 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.

CHANGELOG.md Outdated Show resolved Hide resolved
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: .coderabbit.yml

Commits Files that changed from the base of the PR and between 650c4c3 and 3ac22fe.
Files selected for processing (1)
  • types/module/module.go (3 hunks)
Files skipped from review as they are similar to previous changes (1)
  • types/module/module.go

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Status

Actionable comments generated: 0

Configuration used: .coderabbit.yml

Commits Files that changed from the base of the PR and between 3ac22fe and 1e2ce43.
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

@kocubinski kocubinski added this pull request to the merge queue Mar 6, 2024
Merged via the queue into main with commit 4edf6b2 Mar 6, 2024
77 of 79 checks passed
@kocubinski kocubinski deleted the kocubinski/refactor-iface-reg branch March 6, 2024 21:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants