Unable to control parsable format from configuration file

[ssbarnea]

In order to make the format compatible with other similar tools, I wanted chage the config to always use parsable but adding format: parsable to the config does not work.

I looked at the code and apparently there is no support to control parsable via configuration file.

[adrienverge]

Sounds like a good addition! Do you want to solve this problem?

This could look like this:

extends: default

format: parsable  # ←

ignore: |
  *.dont-lint-me.yaml

rules:
  key-duplicates: enable

[jgstew]

Putting this in the config file would have to affect this line in cli.py

https://github.com/adrienverge/yamllint/blob/8eebab68ab31138c7ef021117897f71fb537b747/yamllint/cli.py#L110

The challenge is that generally the command line args would override any config file specified configuration if both are specified and they conflict. Right now since only the command line args exist, then adding this to bubble up from the config file would require making sure no conflicting command line args are specified.

[mohkale]

Tangentially related, could we also add an option to configure the actual parsable output format?

"%(file)s:%(line)s:%(column)s: [%(level)s] %(message)s"

I'm using emacs and because wrapping the level in [] isn't standard my editor can't parse the level by default. I'd like to just change it to

"%(file)s:%(line)s:%(column)s: %(level)s %(message)s"

if possible?

EDIT:

Might make more sense to add a custom output format.

[adrienverge]

Tangentially related, could we also add an option to configure the actual parsable output format?

"%(file)s:%(line)s:%(column)s: [%(level)s] %(message)s"

The idea is smart but it would leak yamllint internal variables, and use a Python representation, which isn´t my favorite option because we would have to maintain this forever, even if we want to change it in the future.

I'm using emacs and because wrapping the level in [] isn't standard my editor can't parse the level by default.

The solution is to use vim. More seriously, how do you integrate yamllint with emacs? There are plugins like https://github.com/krzysztof-magosa/flycheck-yamllint. Also, instead of using the command yamllint ..., could you remove brackets on the fly with something like yamllint ... | sed 's/\[//g;s/]//g'?

[mohkale]

The solution is to use vim.

Lol :rofl:. I do but only for small files or small edits, where linting rarely comes in useful.

There are plugins like https://github.com/krzysztof-magosa/flycheck-yamllint.

Yes, but that's pretty much deprecated. flycheck has builtin support for yamllint and that brings on the fly linting to your buffer (much like vims ALE), but I was talking more about M-x compile which is closer to vims jumplist.

Observe how warning and error are both highlighted as red because emacs can't parse the level of the message by default (you can configure it to if you have to, although I would've preferred not having the [] altogether).

Also, instead of using the command yamllint ..., could you remove brackets on the fly with something like yamllint ... | sed 's/[//g;s/]//g'?

Oh, did not consider that. Yeah, that should work fine with my lint script. Thank you :smile:.

[ssbarnea]

Closing this because I no longer think that this is really the kind of feature that needs to be configurable. Only recently I removed support for it from ansible-lint, just because it caused the tool to behave very differently based on user config (cause confusions).

Anyone that parses the output, should always pass the arguments for making the desired output explicit.