On the classification, scope, and general usefulness of the no-tabs rule

[andras-kth]

Apparently, the no-tabs rule causes considerable grief with arguably very limited benefit, considering that any syntactic/formatting issues with TAB characters are handled by the relevant parsers long before the actual rule has a chance to check for TABs.

Consequently, I don't think that the classification (or tag) for this rule as "formatting" is correct.

Since the rule is checking for TABs in parsed and syntactically correct key and values,
my first suggestion is to change the tag for this rule to. say, experimental.

As for the scope of the rule, although YAML does allow TABs in both keys and values,
I can see that having TABs in keys for Ansible is never meaningful; so, checking that makes
sense, but having TABs in values (or "payloads" as someone else put it) can happen in a variety
of valid scenarios. Unfortunately, the lineinfile module on the allow_list is only one of many
potential use cases. The most obvious and very similar one being blockinfile, but snippets
from any code or configuration that requires TABs (e.g. Linux kernel code, Makefiles,
named.conf, etc.) could easily end up in vars: as well. In my mind, ansible-lint has no
business checking values, since the chances of false positive are close to 1.

Based on the above, my second suggestion is to limit TAB-checking to keys.

Personally, I find that this rule is unnecessarily taking sides in yet another holy war.

What's next? Checking for # vim:.* stanzas? 😈

Personally, I've yet to see an example of this rule alerting on a true positive, which is why I'm wondering
about the general opinion about the usefulness of this particular rule. As far as I can tell, polls are not supported here, although GitHub does have an app for that; so, I'll just number the options and hope to receive feedback in comments with the relevant number.

1. Very useful: I've seen several true positives
2. Moderately useful: I've seen some true positives
3. Undecided: I haven't seen this rule triggered yet
4. Mostly annoying: I've yet to see a true positive
5. Completely useless: I get way too many false positives

[konstruktoid]

As for the scope of the rule, although YAML does allow TABs in both keys and values

From https://yaml.org/spec/1.2/spec.html#id2775170 and https://yaml.org/spec/1.2/spec.html#id2777534:
"YAML recognizes two white space characters: space and tab."

"To maintain portability, tab characters must not be used in indentation, since different systems treat tabs differently. Note that most modern editors may be configured so that pressing the tab key results in the insertion of an appropriate number of spaces. The amount of indentation is a presentation detail and must not be used to convey content information."

What's next? Checking for # vim:.* stanzas?

That's just to rule out any emacs user ... ;)

[andras-kth]

@konstruktoid
Would you mind explaining your point with citing the YAML specifications?

The first quote is largely irrelevant when it comes to "content" (such as keys and values),
where white-space would be either escaped or deemed to be part of content by indentation.

E.g. the following is fully compliant YAML:

"\tmy\tkey\twith\ttabs\t": "\tmy\tvalue\twith\ttabs"

user@host:~$ yaml='"\tmy\tkey\twith\ttabs\t": "\tmy\tvalue\twith\ttabs"'
user@host:~$ printf "$yaml\n"
"       my      key     with    tabs    ": "    my      value   with    tabs"
user@host:~$ printf "$yaml\n" | yq .
{
  "\tmy\tkey\twith\ttabs\t": "\tmy\tvalue\twith\ttabs"
}
user@host:~$

The second quote is part of my point: TABs are not allowed in indentation,
hence any compliant YAML parser will complain if TABs appear in indentation.
The no-tabs rule never sees indentation, it only processes pre-parsed content.

BTW, what's your experience with the hit rate of this rule?
Where are you on my 5-point scale?

[konstruktoid]

Would you mind explaining your point with citing the YAML specifications?

Too give context and relevance, and so that people that reads this discussion doesn't actually have to look up the specifications.

Where are you on my 5-point scale?

Very useful or perhaps Moderately useful since my editor converts tabs to spaces when working with yaml files.

[andras-kth]

since my editor converts tabs to spaces when working with yaml files.

Well, exactly... so, why would you need this then?
In case someone messes with you and puts in TABs in your files? (LOL)

Seriously, the only time I have TAB characters in a YAML file is when
I need to have them, because the target where the payload will
eventually end up requires TABs. In that scenario, it's a major
pain to get linter errors...

AND, usually, these happen in literal blocks, where adding # noqa
is not an option. Luckily, there are other options (when they work,
which is not always the case), i.e. using tags or skip_list...

[konstruktoid]

since my editor converts tabs to spaces when working with yaml files.

Well, exactly... so, why would you need this then?
In case someone messes with you and puts in TABs in your files? (LOL)

Well, yes? Pull Requests?
Same reason I use Github Actions or other CI/CD to lint and code check.

[andras-kth]

🤦 Right.... SORRY! Now, that's starting to make a lot more sense.... 😏
It's all a matter of perspective.

[ssbarnea]

In fact polls are supported via https://github.com/apps/polls ;)

IMHO, the need to use tabs in yaml files is so low that I prefer to always escape them when needed, even using file-templates in order to avoid use of tabs inside yaml. Too often I seen bugs related to them, including accidental conversion of them to spaces. From my point of view using noqa to silence a false-positive is an acceptable cost.

[andras-kth]

In fact polls are supported via https://github.com/apps/polls ;)

Are you sure? I've tried to create one and it didn't work.
Let's see if it does now (or what am I doing wrong).

/polls '1 - yes' '0 - no'

the need to use tabs in yaml files is so low

And, this statement is so very subjective...

Too often I seen bugs related to them, including accidental conversion of them to spaces.

Right.... overzealous editors...

From my point of view using noqa to silence a false-positive is an acceptable cost.

Except that # noqa is often not an option, when TABs are actually needed for formatting
content that stays readable (i.e. in some sort of literal context).

[ssbarnea]

If you are trying to convince me please provide a link or two from real projects where tabs are used, it would make the selling easier.

Regarding polls, my mistake, it was activated on a single repository, I just enabled it on entire organization and it should work. Please make the options explicit like "no-tabs should remain enabled by default", "no-tabs should be disabled by default", "no-tabs should only be a warning", "i don't care". Keep in mind that any modification to the poll resets all exiting votes.

[andras-kth]

If you are trying to convince me please provide a link or two from real projects where tabs are used, it would make the selling easier.

As I said earlier, any task that needs to manipulate files that include TABs traditionally would qualify.
See, e.g. https://github.com/pulp/pulpcore/blob/master/.ci/ansible/start_container.yaml#L56

Another class of common use cases is when a TAB is part of a regular expression, as in
https://github.com/ibm-cloud-architecture/icp-admin-bootcamp/blob/master/labs/playbooks/install-docker-rhel.yaml

BUT, these are by no means a majority.