feat!: Cosmos SDK v0.46.0

[aljo242]

This PR does the following:

• updates Cosmos SDK to v0.46.0
• updates spn to latest
• updates ibc-go to v5 temporary branch

This PR does NOT

• update application templates
• update proto compilation

[github-actions]

Visit the preview URL for this PR (updated for commit 638abc8):

https://ignite-go-docs--pr2675-feat-sdk-v0-46-0-0zoge0jm.web.app

_{(expires Thu, 04 Aug 2022 17:51:19 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

[aljo242]

This commit was made to a mock file which might be undesirable. We need to implement this interface, but I wasn't sure how to generate the mocking code.

[jeronimoalbi]

This commit was made to a mock file which might be undesirable. We need to implement this interface, but I wasn't sure how to generate the mocking code.

I think you can do it with something like:

mockery --srcpkg github.com/cosmos/cosmos-sdk/x/bank/types --name QueryClient --structname BankClient --case underscore --print

What I'm not sure is where to add the generator comment, maybe somewhere in the ignite/services/network/network.go. If so the comment should look like:

//go:generate mockery --srcpkg github.com/cosmos/cosmos-sdk/x/bank/types --name QueryClient --structname BankClient --case underscore

Or maybe to the Makefile, because it's generating the mock for an interface defined in a dependency.

Also another alternative would be that we define our BankClient interface and generate the mock from it. It would embed the QueryClient.

By the way, I just noticed that the StakingClient in the ignite/services/network/mocks/staking_client.go file should also be added in a similar way.

[tbruyelle]

What I'm not sure is where to add the generator comment, maybe somewhere in the ignite/services/network/network.go. If so the comment should look like:

//go:generate mockery --srcpkg github.com/cosmos/cosmos-sdk/x/bank/types --name QueryClient --structname BankClient --case underscore

@jeronimoalbi Indeed there's already some go:generate instructions in network.go/network.go, but also in network/testutil/mocks.go. If I get the logic the external interfaces are in testutil, so maybe BankClient should be added there.

Something like

diff --git a/ignite/services/network/testutil/mocks.go b/ignite/services/network/testutil/mocks.go
index 54fd02f8..28244037 100644
--- a/ignite/services/network/testutil/mocks.go
+++ b/ignite/services/network/testutil/mocks.go
@@ -2,6 +2,7 @@ package testutil

 import (
        "github.com/cosmos/cosmos-sdk/crypto/keyring"
+       banktypes "github.com/cosmos/cosmos-sdk/x/bank/types"
        campaigntypes "github.com/tendermint/spn/x/campaign/types"
        launchtypes "github.com/tendermint/spn/x/launch/types"
        profiletypes "github.com/tendermint/spn/x/profile/types"
@@ -32,3 +33,8 @@ type RewardClient interface {
 type AccountInfo interface {
        keyring.Info
 }
+
+//go:generate mockery --name BankClient --case underscore --output ../mocks
+type BankClient interface {
+       banktypes.QueryClient
+}

[fadeev]

While upgrading an IBC-enabled module (in a test project) I've noticed that having a dependency on the cosmosibckeeper makes it difficult to upgrade the module without also proposing changes to Ignite.

wdyt about proposing to have a package like this in cosmos/ibc-go somewhere, so that we can have: less code in the template and an easier path for version upgrades?

[aljo242]

Added panic on the GetPubKey calls. We can resolve this later with the following issue

[aljo242]

While upgrading an IBC-enabled module (in a test project) I've noticed that having a dependency on the cosmosibckeeper makes it difficult to upgrade the module without also proposing changes to Ignite.

wdyt about proposing to have a package like this in cosmos/ibc-go somewhere, so that we can have: less code in the template and an easier path for version upgrades?

I'm always for adding less code in the templates to make upgrades easier. I think a goal for our new releases should be to decouple new chains from importing our core packages. There must be a way to provide lots of utility functions to consumers without having them import everything.

If we had multiple go modules within this repo, wouldn't this be possible?

[aljo242]

Good to merge?

[tbruyelle]

Good to merge?

I wanted to test all the tutorials with the new binary, but I ran out of time. Has anyone done this yet ?

[ilgooz]

Good to merge?

I wanted to test all the tutorials with the new binary, but I ran out of time. Has anyone done this yet ?

Since these changes will be merged to another branch (feat/sdk-ibc-upgrade) and not develop directly, I think we will have a chance to run tutorials before merging it to develop?

We will also need to merge other PRs that will change our templates. So probably we can cut from time if we just test tutorials after all these are merged.

I will add this as an item to the issue description.

[ilgooz]

https://github.com//issues/2673

[tbruyelle]

https://github.com/[/issues/2673](https://github.com/ignite/cli/issues/2673)

Yep I have this issue in mind, but also didn't have the time to work on it!