Enforce INI options separated by spaces, newlines, pipes or other characters

[andreoliwa]

Problem

Some keys in the setup.cfg file contains a list of values separated by spaces instead of commas. E.g.:

[tool:pytest]
addopts = -v --doctest-modules

Possible solution

• [ ] Change [nitpick.files."setup.cfg"]comma_separated_values = to be more generic
• [ ] Deal with generic lists with a separator
• [ ] Split this in a way it's possible to spread in 2 files, flake8 and isort:

[nitpick.files."setup.cfg"]
comma_separated_values = ["flake8.ignore", "flake8.exclude", "isort.skip", "isort.known_first_party"]

• [ ] Deal with multiline options (e.g.: commands, omit (coverage)
• [ ] Proper testing of top section with separated values (search for comments in the code)
• [ ] See docs/ideas/ini.toml for implementation ideas

[finswimmer]

Hello @andreoliwa,

this topic and the examples shown in https://github.com/andreoliwa/nitpick/blob/develop/docs/ideas/ini.toml#L9, shows that there is a need to add some options to the several styles to manipulate the output.

In the implementation ideas you are using some kind of marker for "magic" keywords. I think mixing those config keywords with things that should go into the output is quite confusing. What's your opinion about introducing a breaking change and move the actually content to a new subtable?

Before:

["setup.cfg".flake8]
ignore__separators = ","
ignore = "E501, E203, W503"

New:

["setup.cfg".flake8]
ignore_separators = ","

["setup.cfg".flake8.content]
ignore = "E501, E203, W503"

This (or similar) clear separation between options and content gives us the opportunity to introduce new options that are doing some magic quite easily.

Thanks a lot for this great project!

fin swimmer

[andreoliwa]

Hi again, @finswimmer. 👋🏻

Thanks for raising the topic for discussion. This issue is still raw, I didn't think yet of a good API or solution to solve this problem.

In the implementation ideas you are using some kind of marker for "magic" keywords.

Exactly. Using the double underscores and mimicking the magic used by SQLAlchemy, Django and other Python projects.

I think mixing those config keywords with things that should go into the output is quite confusing.

Thanks for the feedback. The "ideas" directory is brainstorming and experimentation. 🧠 I'm not even sure if the ideas are feasible in code. 😅

What's your opinion about introducing a breaking change and move the actually content to a new suitable?

One problem I see in your example is that we will have a reserved word "content". No configuration file can ever have a key named "content".

I came up with the magic dunders in order to:

• Avoid having more reserved keywords;
• Make it easier for the plugins to discard certain key/value pairs when reading the styles
• Keep the style file closer to a real config file. Usually, the only thing needed is to prefix each section with filename and extension.

["my-file-name.my-extension".some.config]
key = value

---

The current JSON plugin has contains_keys and contains_json reserved keywords. It was an idea that worked at the beginning of the project, but now I think it was bad and it could be done differently.

The YAML plugin does way more things than the JSON plugin and it has one magic dunder.

---

Another point to consider: would the "content" sub-table be used in all formats (YAML, INI, JSON), or only in INI files? I'm not sure if other formats other than INI could also need a configuration for "separator of multiple values".

---

Sorry if my thoughts are a bit chaotic, but I wrote this comment based on what I remember. I haven't changed the INI plugin in a while, and I did the YAML plugin recently.

Maybe some good ideas from YAML plugin could be reused in the INI plugin.