-
Notifications
You must be signed in to change notification settings - Fork 8
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
Support configuration using pyproject.toml #16
Conversation
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.
👍
Co-authored-by: Kirill Druzhinin <[email protected]>
src/dbt_score/config.py
Outdated
"""Configuration for a rule.""" | ||
|
||
severity: int | None = None | ||
params: dict[str, Any] = field(default_factory=dict) |
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.
Could this be named config
(also in Rule.params
-> Rule.config
)?
Reason is, I find it confusing to have these 2 concepts, which are fundamentally the same but named differently
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 this actually prevents confusion because these things are not the same IMO. Yes both are to configure a Rule
, but one configuration is input for a method whereas the other also does other things (update severity). I am open to change it, maybe @druzhinin-kirill has an opinion on what is less confusing?
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.
Rule.config_params 😄
No strong opinion, however, I would prefer avoiding key mismatch variable names:
return RuleConfig(severity=severity, params=rule_config)
so either variable is params
, or the argument is rules
(only if it's achievable for zero cost, super minor anyway).
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.
From the user point of view, this is all "rule config", right?
Now internally the config is divided in two, severity
and params
/config
. I don't think it's an issue, we could do something like
return RuleConfig(severity=severity, config=config)
which I believe is self explanatory, and doesn't require the use of multiple terms? WDYT?
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.
From the user point of view it's indeed all the same, it's internals only.
Ok I will go for using config
inside RuleConfig
👌
Co-authored-by: Kirill Druzhinin <[email protected]>
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.
🚀
Support general configuration and rule configuration stored in
pyproject.toml
.