Consider simplifying ini config parsing

[Lotram]

I started working on static config models. While doing that, I added some tests on the load.parse_file function.
I then realized that all the parsing done in ini2toml_plugin is not used when parsing a ini file (except for the ini2toml command).

I see 2 problems with that:

• The result of parse_file is quite different, depending on the input file (toml vs ini)
• The ini parsing logic is duplicated between parse_file and ini2toml_plugin, with different results

Can't we simplify this ? We could either

• add ini2toml to required dependencies and always use it when parsing an ini file (we could even write the toml file ourselves ? )
• keep it as optional, but force the user to install it if they want to keep an ini file (or suggest to run it once to use a toml file instead)
• same, but always raising an error when trying to parse an ini file, and ask the user to migrate to toml file, using the ini2toml command

I know those solutions are drastic, and we probably want to deprecate it first, but I think we should avoid having multiple ways to parse a config file, and multiple results.

[ryneeverett]

I'd like to avoid adding ini2toml as a required dependency if possible because that would be a burden on distributions since I don't believe ini2toml is widely packaged.

I gather from your "drastic" solutions that the problem is severe? Could you give some examples or maybe a test that demonstrates the issue?

related: #1042

[Lotram]

"drastic" might not be the right word, and the problem is not actually severe. Basically, when parsing the ini file, all the int / boolean values are parsed as strings, and the comma-separated lists are strings as well, instead of string.

So everything is handled by pydantic, but having to support two such files (+ the ini2toml parser) can lead to more errors (as we saw with flavors). So I think we should aim at having only one file (toml) in the future.

So I guess the actual solutions depends on how fast / slow we want to implement breaking changes

[ryneeverett]

I agree that we should probably converge on only supporting toml at some point, but I'm not inclined to drop ini support just because there are probably more bugs which we haven't discovered. (And I agree that those bugs are probably waiting to be found!)

My thought is that at some point we will either discover severe bugs which are impractical to fix or impose a maintenance cost on the rest of the code base we don't want to pay. But at this point it seems like continued ini support is zero cost.

One step I do think would make sense to take immediately would be for the documentation to say that toml is "recommended" and to flip the tabs so that toml is first and default.

[Lotram]

What do you think about also logging a deprecation warning when parsing ini ?

[ryneeverett]

I think that would go hand-in-hand with undocumenting ini configuration entirely. I don't think we're at that stage yet.

My main point here is that breaking changes need to be justified by concrete benefits either in feature development, in maintainability, in elimination of a bad user experience, or some combination thereof. I haven't seen any of those benefits yet.

[Lotram]

My main point here is that breaking changes need to be justified by concrete benefits either in feature development, in maintainability, in elimination of a bad user experience, or some combination thereof. I haven't seen any of those benefits yet.

IMO, aiming at removing the ini2toml plugin, plus the ini parsing in load.py is an improvement on maintainability.
As long as we don't modify it, it's not an issue (as you said in your comment earlier, for now it has zero cost), but if we ever decide it becomes too complex to maintain, we can't deprecate it and remove it right away.

My point is, since it seems we agree that in the long run, we should only support toml, the faster we start the deprecation process, the faster we can remove it, and when the time comes we decide it needs to be removed, we can do easily, without waiting for a deprecation phase.

[ryneeverett]

What is the maintenance cost of the ini2toml plugin?

We share an intuition that ini is not going to be worth maintaining in the long run, but I don't think we should break backwards compatibility on the basis of intuition. I want to see evidence that ini actually imposes a non-trivial cost.

[ryneeverett]

I guess the cost you're seeing is that as you modify the configuration in between parsing and validation, the formats are different. They aren't actually different when it comes to the table keys ('general', flavors, targets), right? So what you're working on doesn't involve any different logic for ini vs toml, right?

If I might make a suggestion, I think you could almost entirely put out of mind the fact that ini support exists. I'm basically suggesting that we immediately move it to a "second-tier support" category which means we're not obligated to test it as thoroughly as toml. Does that alleviate the maintenance cost you're encountering?