support configuring px using toml (or yaml or json or anything other than ini)

[DetachHead]

today i learnt the hard way that despite what the syntax highlighting in vscode and github will have you believe, comments in .ini files only work if they're placed at the start of a line:

[settings]
; Idle timeout in seconds for HTTP connect sessions. Valid integer, default: 30
idle = 300 ; 5 minutes

in this example, the first comment works, but the second one doesn't. instead the value for idle gets set to the string "300 ; 5 minutes" and causes px to crash.

it would be nice if px could be configured using a less terrible language such as toml.

[genotrance]

I explored four approaches, from simplest to most complex:

• Strip inline comments before passing to configparser - preprocess the file content to remove ; and # after values. ~10 lines of code, no new dependencies, no user-visible change.
• Keep INI but convert to TOML internally before parsing - translate INI syntax to TOML on the fly and use a TOML parser. Fixes comments, adds native type parsing, but users still see .ini files.
• Switch to TOML officially - new default .toml config, migrate existing INI files, ship TOML going forward.
• Switch to YAML - same as above but with YAML and a heavier dependency (PyYAML).

All four fix the inline comment problem identically. Options 3 and 4 introduce a new config format to learn,
migration tooling, updated docs, and a deprecation path for existing users - but Px's configuration is simple and stable, so the richer
features of TOML/YAML don't add much practical value here.

Leaning toward option 1 or 2. Thoughts?

[DetachHead]

thanks for considering this!

my vote in order of most preferred to least preferred would be 3, 4, 1, 2. i feel like options 1 and 2 have the potential to introduce other unexpected behavior that may not be immediately obvious.

regarding option 3, i was thinking both toml and ini could be supported. that way, users can use toml if they want without there being any disruptive backwards incompatible changes. px could first look for px.toml then fallback to px.ini if there's no toml file.

however it's understandable if you would prefer to keep only one configuration format. in which case, another option could be to keep both formats for a while and add a deprecation warning to the ini format, then remove it later on in a future release.

thanks for creating px by the way. it's been a huge life saver with the annoying corporate proxy i have to put up with

[ponchofiesta]

The px configuration file is small and uncomplicated. Personally, I would only consider switching to a new format if it were to become more complex (involving lists, hierarchies, etc.). Otherwise, it is currently not worth the effort.

And a few thoughts regarding other formats:

• JSON does not support comments and, due to its complex syntax, is poorly suited for configuration files intended to be edited by humans.
• YAML can lead to issues caused by incorrect—and often hard-to-spot—indentation errors. The special handling of certain values ​​can also prove to be a pitfall.
• If I were to choose any format, TOML would be the most likely candidate—even though I still haven't quite mastered its syntax myself. But only if the config uses more complex data types.

[DetachHead]

Personally, I would only consider switching to a new format if it were to become more complex (involving lists, hierarchies, etc.). Otherwise, it is currently not worth the effort.

i understand this concern but i disagree. there are plenty of issues with INI files which is why many projects are moving away from them (in fact i just found out while writing this comment that it isn't even standardized).

the python ecosystem in general is moving towards TOML, so i feel as time goes on users will just come to expect tools to be configurable with TOML

i do 100% agree with your other points though. and i'm not the biggest fan of toml myself, but i do prefer it over the alternatives at least.

just my 2 cents however, ultimately it's @genotrance's decision