GitCommitBear: Create a ruleset called 'coala' that all coala repos can enable

[coala-bot]

Opened via gitter by @jayvdb

[satwikkansal]

Do you mean a setting like coala_ruleset = True, which will automatically enforce all the guidelines at https://coala.io/commit

[Makman2]

hm this is coala specific, not sure we want to bother users with it. Maybe we should generally think about such a ruleset-concept which can be enabled differently?

[Makman2]

(especially something like coala_ruleset will appear in the help of the bear implementing it)

[satwikkansal]

@jayvdb @Makman2
Just want to check if I'm thinking in right direction or not.

hm this is coala specific, not sure we want to bother users with it.

If it's coala-specific, we already have it in some section in our .coafile. I can't understand why would we need to enable it differently.

Or is the issue about adding functionality to define rulesets (combination of settings for a bear) and letting anyone use them.
Something like commit_rules = coala
and this ruleset is some combination of settings for GitCommitBear defined either in

• GitCommitBear
• Some custom configuration file (xml/json or our own .gitcommitbear_rules) so that the users can just add this file in a .ruleset directory and coala will recognize the settings on its own. This will allow users to share their bear rulesets or use other people's ruleset.

[Makman2]

Or is the issue about adding functionality to define rulesets (combination of settings for a bear) and letting anyone use them.

I think I meant this. I remember that adding a setting to GitCommitBear would complicate things in terms of consistency and redundancy (because when defining a ruleset, you don't need to provide other settings).

I'm not sure what's the best approach to rulesets currently, so @satwikkansal feel free to try different possibilities and post them here ;)

[satwikkansal]

So, I think instead of defining the ruleset in the bear's implementation or coala-bears codebase, we should develop a generic way in coala-core for creating rulesets and using them in projects.

The ruleset might be defined in a special file-format like .ruleset or .json for defining bear specific settings as I discussed above, and then in the .coafile we can do something like

[commit]
ruleset = ../rulesets/GitcommitBearRuleset
bears = GitCommitBear

[jayvdb]

Ya, creating a set of commit styles (rulesets), like inline documentation styles .coalangs was what I had in mind.

The problem is that the style varies too much between projects, and all the implementation is in the bears repo, so I think this should remain in the bears repo. In that way it differs from language and documentation styles, for which there is a very strong incentive to use standards. Commit style standards are a long way behind in terms of acceptance.

We don't want to be releasing new versions of coalib and bears each time someone wants to define a ruleset for a different combination of options.

Long term, after the feature set of commit styles has stablised, we might have a separate repo for rulesets, and the bear fetches a ruleset if the requested one doesnt exist.

Single repo projects can define their style in the .coafile.
Orgs or People with lots of repos want to define it once.

It should be possible to do:

[commit]
commit_ruleset = https://foo.com/my_org_commit_style.ruleset
bears = GitCommitBear

And that leads me to describe a more generic solution for this: coala/coala#4072

[Makman2]

Maybe we should also allow to combine rulesets, so we have a single rules setting:

rules = coalaCommitRules + StandardMarkdownRules

[satwikkansal]

Combining rules sounds like a good idea (but can be split into another issue imo). I think starting steps for this may be:

• Add support in coala core for:
  • An optional setting for every bear called bearname_rules.
  • The value of this setting can be a "local path" or a "http url".
  • The file referred by the value of this setting is a .ruleset file.
• Then create a .ruleset file for commit rules in coala.
• Host the .ruleset file somewhere (in a ruleset repo of coala, or just cache it in bears repo locally for now)
• Finally, add the gitcommitbear_rules setting in the .coafiles.

Also, not sure whether the .ruleset file should be:

• Just specific to a bear (like gitcommitbear_ruleset)
• Non-specific or mix of bear-specific and non-specific settings (to me, this option seems more like inheritance of a .coafile)

[Makman2]

That's the question whether they should be specific. As there are rules that span multiple languages. Consider e.g. MaximumPerformantCode rulesets which contains setting for every language/bear to enable all even most aggressive optimization checks in coala (such don't really exist yet, though in principle). So imo we will hit the limit of bear-bound rulesets very fast.

[satwikkansal]

IMO the MaximumPerformantCode type rulesets will better suit "aspects" based configurations (because then Performance in itself would be an aspect and all we need to do is providing the right setting values for that aspect)

[Makman2]

Yeah right aspects would solve this a bit, still there are rulesets which will span multiple bears and their settings.

[satwikkansal]

Nod. So if the approach described in #1453 (comment) seems okay, shall I create a corresponding issue in coala core and start working on it.

PS: I don't exactly know the process of dealing with "status/needs design" labeled issues.