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

feat(wip): add depinject support for app v2 #3868

Conversation

crodriguezvega
Copy link
Contributor

@crodriguezvega crodriguezvega commented Jun 16, 2023

Description

Still work in progress.

closes: #3560

Commit Message / Changelog Entry

imp: add depinject support for app v2

see the guidelines for commit messages. (view raw markdown for examples)


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (see CONTRIBUTING.md).
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards and Go style guide.
  • Wrote unit and integration tests.
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/).
  • Added relevant godoc comments.
  • Provide a commit message to be used for the changelog entry in the PR description for review.
  • Re-reviewed Files changed in the Github PR explorer.
  • Review Codecov Report in the comment section below once CI passes.

@crodriguezvega crodriguezvega linked an issue Jun 16, 2023 that may be closed by this pull request
3 tasks
@crodriguezvega crodriguezvega changed the title wip: add depinject support for app v2 feat(wip): add depinject support for app v2 Jun 16, 2023
@faddat
Copy link
Contributor

faddat commented Jun 16, 2023

Will you want to keep an appv1 app.go around?

I've been thinking about this lots while writing the upgrade...

// App Wiring Setup

func init() {
appmodule.Register(&modulev1.Module{},
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This call to Register complains with:

cannot use &modulev1.Module{} (value of type *"github.com/cosmos/ibc-go/v7/modules/core/module/v1".Module) as protoreflect.ProtoMessage value in argument to appmodule.Register: *"github.com/cosmos/ibc-go/v7/modules/core/module/v1".Module does not implement protoreflect.ProtoMessage (missing method ProtoReflect)compiler[InvalidIfaceAssign](https://pkg.go.dev/golang.org/x/tools/internal/typesinternal#InvalidIfaceAssign)

But I don't know why it doesn't implement protoreflect.ProtoMessage...


package ibc.core.module.v1;

option go_package = "github.com/cosmos/ibc-go/v7/modules/core/module/v1";
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see SDK has this api folder at the root where the .pb.go files are located. for now I put it in modules/core/module/v1. Looking for feedback where the best location would be.

@crodriguezvega
Copy link
Contributor Author

Will you want to keep an appv1 app.go around?

I've been thinking about this lots while writing the upgrade...

I haven't given that much thought yet, or discussed with the rest of the team. I guess it doesn't hurt to keep both v1 and v2 for the time being? What pros/cons do you see of keeping both?

@faddat
Copy link
Contributor

faddat commented Jun 16, 2023

Well, it seems like v2 is going to be much easier to work with. I suppose that if there are chains that wish to use appv1, then we should keep a simapp for them so that they can reference it.

That said, I've noticed a lot of the work that I'm doing is abstracted away by v2. Should we open an issue?

@jackzampolin
Copy link
Member

we should just use v2 IMO

@faddat
Copy link
Contributor

faddat commented Jun 30, 2023

Kinda vibing this way, too, though I think ideal is using both :/

Maybe we follow the SDK's lead:

  • use v1 but we use go build tags to not use it by default
  • use v2 by default

@crodriguezvega
Copy link
Contributor Author

I think I have made some progress with this, but I am going to close this PR and open a new one.

@crodriguezvega crodriguezvega deleted the carlos/3560-support-sdk-dependency-injection-for-v2-apps branch July 9, 2024 12:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support SDK dependency injection for v2 apps
3 participants