added second rules example rules_SAMPLEv2.py #7
Conversation
|
I gotta admit, I'm having a hard time understanding why the repo needs another example rules.py file. Is this something better handled through documentation? Help me out here, please. |
|
Okay, had another look and realized that you've turned the rules.py into code instead of just a data structure. Generally speaking, I don't get excited about turning configuration into code like this. If this were an example of domain-specific language for configuration, that would be useful indeed, but this is really going to lead to more copy/paste code in the long-run. It's clever, and I think it's good as a solution to a sticky data structure problem, but I don't think we want to start putting stuff like this in the main folder. It will only confuse most users. I'd be open to exploring an "examples" folder under the project root where this could go. I am not 100% sure if it's the right way to proceed. It really needs even more documentation than it already has, so that the data structure being built in the procedure is also commented. What do you think? |
|
Yes, there is a chunk of code, but it also simplifies the way that a rules file needs to be modified such that it eliminates the need for the end user to actually create a dictionary themselves (which is very prone to typo etc)... maybe I need to add some additional verbiage around how to use it.. it makes managing / modifying rules (especially large ones) substantially easier. |
|
An examples folder is fine.. but this is also labelled (sample) shrug |
|
Thoughts? |
|
I'm still holding on this, mostly because I'm planning some bigger things for configuration. I think the entire way that HBLink is configured is broken. I would like for configuration to be handled consistently across different modes and apps (if possible). That's not to say that your approach won't be considered. It's just "not yet", that's all. I'll keep the ticket open for now. |
|
What is the other approach, I’m happy to help out and write some handlers...
… On Feb 28, 2021, at 9:15 AM, Randy Hall ***@***.***> wrote:
I'm still holding on this, mostly because I'm planning some bigger things for configuration. I think the entire way that HBLink is configured is broken. I would like for configuration to be handled consistently across different modes and apps (if possible). That's not to say that your approach won't be considered. It's just "not yet", that's all.
I'll keep the ticket open for now.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAZIFMEQB43JIRX7MPXX7LTBJTZDANCNFSM4T6UW5DQ>.
|
Added another rules_SAMPLE, using this method it is easier to curate larger rulesets with less opportunity for error when directly editing dictionary structures. The new rules sample file is rules_SAMPLEv2.py and is of course python, instead you enter information into lists in a specific way and then pass those lists into a function that generates the appropriate dictionary which bridge.py uses for it's rules.