feat: make epochs standalone.

[puneet2019]

Closes: #2522 , stale/closed previous PRs #2550, #2544
some questions

• proto scripts - to test if they go into correct folder.
• the v14 itself, may be we can drop vAnything, and start with v0? ( just tried with versioning )
• tests no longer have the entire app/ simapp - is this ok?

What is the purpose of the change

allows to import epochs module..

Brief Changelog

Testing and Verifying

• tried importing it in one of the apps with cosmos-sdk v45.12
  This change is a trivial rework / code cleanup without any test coverage.

Documentation and Release Note

• Does this pull request introduce a new feature or user-facing behavior changes? (yes / no)
• Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? (yes / no)
• How is the feature or change documented? (not applicable / specification (x/<module>/spec/) / Osmosis docs repo / not documented)

[puneet2019]

I think it should be non breaking.. but will let the labelling be done by the team
ideally best if can support both cosmos-sdk v45.xx and v46.xx

[ValarDragon]

Awesome! Thanks for working on this! It'll be at least a day before I can dedicate time to review though

On quick glance, the proto looks right to me, up to what our decision for the x/epochs first version is. (Is it version 1, 2, or 14)

Tests not having entire app/simapp is a feature, as long we have all the equivalent functionality tested somewhere! (May mean that we copy some x/epochs integration tests into a new tests/epoch package. Will look out for this in review)

[puneet2019]

Awesome! Thanks for working on this! It'll be at least a day before I can dedicate time to review though

On quick glance, the proto looks right to me, up to what our decision for the x/epochs first version is. (Is it version 1, 2, or 14)

Tests not having entire app/simapp is a feature, as long we have all the equivalent functionality tested somewhere! (May mean that we copy some x/epochs integration tests into a new tests/epoch package. Will look out for this in review)

epochs internal is being tested via unit tests, but the apptestingKeeper has simapp which still imports epochs as a package.

[puneet2019]

@ValarDragon @mattverse could you let me know what version you want? or should I remove and kept it ..../x/epochs?
I see some conflicts, will resolve and do the required changes in a go.

[mattverse]

I personally think we don't need semantic versioning for the epoch package itself, we can go without versioning just as we do with other sub-packages(osmomath or osmoutil package).

Also, apologies to the late review that causes all the merge conflicts 😭 , planning to review this as this PR has the versioing fixed

[puneet2019]

I personally think we don't need semantic versioning for the epoch package itself, we can go without versioning just as we do with other sub-packages(osmomath or osmoutil package).

Awesome, done the versioning, removed it

Also, apologies to the late review that causes all the merge conflicts 😭 , planning to review this as this PR has the versioing fixed
No issues on this one, conflicts are easy

[puneet2019]

btw

$ go install github.com/osmosis-labs/osmosis/x/epochs@f17c63b805b1eecd3612018b47da0a64da9e62
go: downloading github.com/osmosis-labs/osmosis/x/epochs v0.0.0-20230220095848-f17c63bbb805
go: github.com/osmosis-labs/osmosis/x/epochs@f17c63bbb805b1eecd3612018b47da0a64da9e62 (in github.com/osmosis-labs/osmosis/x/epochs@v0.0.0-20230220095848-f17c63bbb805):
        The go.mod file for the module providing named packages contains one or
        more replace directives. It must not contain directives that would cause
        it to be interpreted differently than if it were the main module.

I get this message, but when I just pick the module version in other project and use it, it just works.
Also

$ go get github.com/osmosis-labs/osmosis/x/epochs@f17c63bbb805b1eecd3612018b47da0a64da9e62

works

Ignore:

Starting in Go 1.17, installing executables with go get is deprecated. go install may be used instead.

In Go 1.18, go get will no longer build packages; it will only be used to add, update, or remove dependencies in go.mod. Specifically, go get will always act as if the -d flag were enabled.

so it is as expected.. ref

[puneet2019]

hey @mattverse https://github.com/osmosis-labs/osmosis/actions/runs/4261170031/jobs/7415166905#step:4:428
Any idea how to resolve this? mostly just fmt things?
Ensure your tools are up-to-date, re-run 'make proto-all' and update this PR. doesn't do anything

[puneet2019]

@mattverse , in case you missed a notification

[mattverse]

hey @mattverse https://github.com/osmosis-labs/osmosis/actions/runs/4261170031/jobs/7415166905#step:4:428 Any idea how to resolve this? mostly just fmt things? Ensure your tools are up-to-date, re-run 'make proto-all' and update this PR. doesn't do anything

Hey @puneet2019, apologies that I missed the last notification. Can you try pulling your local git to latest main and then merging this branch then run make proto-all? This should hopefully solve the issue mentioned above.

[puneet2019]

it was make run-querygen
hmm.. looks like proto-all doesn't run querygen ...
and I guess the IDE was running go fmt which caused some white spaces to be erased

[p0mvn]

Thank you! Please add a change log entry and refresh the PR, and we can merge it!

[puneet2019]

@p0mvn @mattverse done

[p0mvn]

LGTM. Thank you