-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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: decouple x/params
from simapp
#12259
Conversation
}, | ||
false, | ||
}, | ||
// { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aaronc Shouldn't we use another app.yaml
for this specific test? I feel like the default app.yaml
from testutil
should contain the minimum modules required for the tested specific module. Here, gov does not fall into this category.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really following. Can you explain more?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I meant is from my understanding the app.yaml of a module should be minimalistic. That means only requiring modules that are dependencies or strictly required for running the module app.
Here we need to add as well the gov module which isn't a dependency of params.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense but seems like the tests were written in a tightly coupled way so they depend on gov... We'll need to do some refactoring of tests probably
x/params/proposal_handler_test.go
Outdated
"github.com/cosmos/cosmos-sdk/x/params/types/proposal" | ||
stakingkeeper "github.com/cosmos/cosmos-sdk/x/staking/keeper" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
im a bit worried about these direct dependencies. It could make versioning harder for us and users. Not sure alternative solutions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There shouldn't be a problem using an expected keeper interface instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think sometimes with expected keepers we still need to import the types. I am not sure it solve that concern then.
It seems it does here tho as the input is only a context for staking, so I will fix that.
However for gov it won't work as we import types as well.
Codecov Report
@@ Coverage Diff @@
## main #12259 +/- ##
==========================================
+ Coverage 66.08% 66.10% +0.01%
==========================================
Files 675 675
Lines 71275 71276 +1
==========================================
+ Hits 47104 47114 +10
+ Misses 21527 21518 -9
Partials 2644 2644
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description
Closes: #12023
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...
!
to the type prefix if API or client breaking changeCHANGELOG.md
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...
!
in the type prefix if API or client breaking change