Multiple local_rule Directories

[Benito-E]

It crossed my mind that it could be beneficial for the -lr and --local_rules options to take multiple directories, so that users can self organize groupings of rules. Whether or not this is a feasible or simple-to-implement feature of course depends on how local rules are loaded internally, But I figured I'd mention the idea.

The only external-solution (not modifying source code) that I've thought of would be to have an external script that takes multiple directories, and dynamically copies the local rules in them into a single runtime-temporary local_rules directory, to be given to VSG. The problem with this is that due to rule filename and classname requirements, separate sets of rules where perhaps there are multiple rule_007.pys, may need to be dynamically renamed, along with the classnames inside the files. Such a workaround would definitely be more effort than its worth to implement, I personally believe.

In any case, this is just an idea, so let me know what you think about it

-Benito

[jeremiah-c-leary]

Evening @Benito-E ,

I would agree the inclusion of multiple local rules would be helpful. That feature has not received any attention from it's inception as I think you are the only person who has actually used it.

I can allow multiple local rules, similar to configurations, and also change the local_rules option in the configuration files to a list.

I could also allow for one level of nesting similar to how VSG organizes it's rules.

Would you have a preference for either method?

--Jeremy

[Benito-E]

Hi again @jeremiah-c-leary,

While I have a preference for the former of the two methods, I also believe both methods would be valuable. The latter of the two methods would be useful even simply for organizing large sets of local rules, and the former of the two methods would be useful for collaboration, if multiple developers had separate sets of local rules that could be mixed and combined; or perhaps if a particular project had an overarching set of rules that all developers were meant to use, and each individual developer was allowed to develop their own set of rules.

The only reason I have a preference for the former of the two methods is because it would theoretically allow for the flexibility to accomplish the both methods: you could accomplish the latter method by having an external script that scanned a directory for directories and passed those names to VSG's --local_rules option.

In any case, I appreciate the enthusiasm and support you have for this project!

-- Benito

[jeremiah-c-leary]

Evening @Benito-E ,

I would agree the former method, allowing multiple local rules via --local_rules, would be the easier of the two methods. One problem I could see with multiple local rules would be with rule id collision. If multiple rules had the same id then it could be difficult to determine which one actually failed. I do not believe this issue goes away with the later method. I suppose the conflicts would need to be managed outside of VSG.

Is this a feature you would like to see implemented or is it a feature that can be deferred. I ask because you are the first person who has asked about local rules in the 6 years I have been developing VSG. I originally added it so others could write their own rules, but I suspect you are the only person who has. I would rather postpone the implementation of this feature if there is no demand for it. Hopefully that makes sense.

In any case, I appreciate the enthusiasm and support you have for this project!

Thanks for the kind words. It is nice to know my efforts are appreciated.

Regards,

--Jeremy

[Benito-E]

Morning @jeremiah-c-leary,

I would rather postpone the implementation of this feature if there is no demand for it. Hopefully that makes sense.

No worries at all, that makes perfect sense! I appreciate the consideration and thought regardless, and if you do decide to implement this feature I'll simply be glad to have contributed to that outcome.

Sincerely,

--Benito

[jeremiah-c-leary]

Evening @Benito-E ,

If it is okay with you then I will make this a deferred issue. In that way the idea will be documented and if you or someone else would like the feature implemented then the issue can be pulled into development.

Regards,

--Jeremy