Cannot import Osmosis code due to use of Cosmos SDK fork

[migueldingli1997]

I am experimenting with building a Cosmos SDK chain that can perform trades on Osmosis using interchain accounts. To do so, I need to be able to construct Osmosis swap messages in the correct format. It would be very convenient if I could import the swap messages from Osmosis but this is complicated by the fact that Osmosis uses a fork of Cosmos SDK. I believe this means that I only have the following two options:

• Replicate the swap message into my code; or
• Use the same Cosmos SDK fork

Both of these options are not that great. If I want to use the latest version of Cosmos SDK, my only option becomes the first one, i.e. to replicate the message in my code. This becomes an even bigger problem if I want to do more than just construct a swap message.

In fact, in my use case, so far I have had to copy the following:

• The pool interface from https://github.com/osmosis-labs/osmosis/blob/v12.1.0/x/gamm/types/pool.go
• Pool logic from https://github.com/osmosis-labs/osmosis/tree/v12.1.0/x/gamm/pool-models
• MsgSwapExactAmountIn https://github.com/osmosis-labs/osmosis/blob/v12.1.0/x/gamm/types/tx.pb.go#L247
• Some osmomath functions from https://github.com/osmosis-labs/osmosis/blob/v12.1.0/osmomath/math.go that the pool implementations make use of

I think in an ideal world, these would be importable without importing all of Osmosis and being restricted to the version of Cosmos SDK that Osmosis is using. Perhaps something similar to https://cosmossdk.io/

[ValarDragon]

So I think theres two parts here:

• Using newer SDK versions
• Using Osmosis with the same SDK version

For generally importing osmosis, I don't see a solution with using newer SDK versions, as SDK versions have API breaks. So even if we used SDK v0.45.x, you couldn't import it from a project on SDK v0.47.x.

With the same SDK version, were pretty blocked on them having more go modules split out into https://cosmossdk.io/. (eg types, store, etc. packages)

We can definitely get osmomath into its own go.mod that can be separately imported! Will need to investigate what it would take for gamm, the problem is all of our tests are integrated tests with the entire Osmosis app. But it will also have SDK imports, which cause the same conflict, until we can a separate SDK import.

The big thing would be to point out to SDK that this is a need, for splitting types into its own go.mod. Then perhaps your chain could import just osmosis types fork (or we can get rid of our type fork with some pretty minor changes being accepted upstream)

[migueldingli1997]

I understand that this is mostly a general problem, not a problem specific to Osmosis. I could see it popping up with any other project that I would integrate with.

That being said, any change towards reducing the problem would be greatly appreciated. Getting osmomath into its own go.mod would be a great start that I would welcome!

[ValarDragon]

Tracking osmomath in #3744

[ValarDragon]

Osmomath has been moved into its own go.mod!

Just realized, it does have one API difference from upstream. Will ask if upstream can get this added so then you could import with either. Which SDK version do you need to import with, 44, 46, or 47?

[migueldingli1997]

Osmomath has been moved into its own go.mod!

Just realized, it does have one API difference from upstream. Will ask if upstream can get this added so then you could import with either. Which SDK version do you need to import with, 44, 46, or 47?

46 currently

[ValarDragon]

I believe it should work with SDK 46?

[dillu24]

@ValarDragon

Not working with SDK 46.1 because sdk.Int.ToDec is removed. Example where this is used in osmomath