Closed zackw closed 3 years ago
I'm not sure what you mean. None of these policies will be enabled unless you enable the theme, and if you switch from freenode to community theme you need to update any configuration specific to those policies to the new names as well.
# Perl::Critic configuration. -*- conf -*-
# we turn on all of the policies at theme level, and then
# we turn off one-by-one the ones I don't like below.
severity = 1
theme =
# ... long list of [-Something::OrOther] ...
This has proven to be troublesome for unrelated reasons, but the replacement is likely to do something similar (the current tentative plan is to have .perlcriticrc list every single policy as either enabled or disabled, and have an ancillary script that ensures the list remains exhaustive).
Regardless, it seems to me that the semantics of a "compatibility alias" ought to be more like "if you write 'Freenode::SomePolicy' in your .perlcriticrc that is interpreted as if you had written 'Community::SomePolicy'" than "'Freenode::SomePolicy' and 'Community::SomePolicy' are independent policies that happen to do the exact same thing". I realize that may require changes to perlcritic core.
I didn't know an empty theme was supported, but I certainly do not support a rc
that enables every installed policy. I already dislike that the theme system will enable policies of that theme depending on what you happen to have installed, which is why I use only unique themes that nothing else will add to when installed. Sorry but I can't help here.
The
Freenode::
policies were recently renamed toCommunity::*
, with backward compatibility aliases in theFreenode::
namespace. The backward compatibility aliases seem to be treated as distinct policies by perlcritic core, which means they're all being processed twice and configuration forFreenode::foo
isn't applied toCommunity::foo
or vice versa.I noticed this when my project's CI broke because all of the Freenode:: policies that we turned off, got turned back on under their Community:: names. The most straightforward workaround seems to be to rewrite the main perlcritic configuration in terms of the Community:: names and then also list every single one of the Freenode:: names as disabled.