cEPs
cEPs copied to clipboard
Config file spec
It would be good to have a cEP defining the specification of the config files we use.
Apparently python has a very very similar PEP which compares some of the really popular ones. We probably would like to read through it. https://www.python.org/dev/peps/pep-0518/
In a nutshell it says:
- JSON: Not human writable easily. No comments allowed
- YAML: Scripts can be run inside a yaml file, implying it has security issues.YAMl specification is just too complicated.
- configparser (ini-like): There is no specification for configparser (It even changes from py2 -> py3)
- Python dict: Is too python specific (no other language can read/write it) and also it's not very human writable
Apparently Python decided to choose TOML (An ini like spec). It seems pretty nice based on a 10 minute review. It's python implementations seem to have a loads
and a dumps
too - to convert from dict <-> str.
Currently we are using a configparser like method. It would be good to have a cEP which defines our spec and make it stable. Or maybe move into an ini-like syntax with spec like toml
agreed
Sincerely,
Lasse Schuirmann
[email protected] http://coala-analyzer.org/ - http://viperdev.io/ - http://gitmate.com/
On 29 June 2016 at 11:48, AbdealiJK [email protected] wrote:
Apparently python has a very very similar PEP which compares some of the really popular ones. We probably would like to read through it. https://www.python.org/dev/peps/pep-0518/
In a nutshell it says:
- JSON: Not human writable easily. No comments allowed
- YAML: Scripts can be run inside a yaml file, implying it has security issues.YAMl specification is just too complicated.
- configparser (ini-like): There is no specification for configparser (It even changes from py2 -> py3)
- Python dict: Is too python specific (no other language can read/write it) and also it's not very human writable
Currently we are using a configparser like method. It would be good to have a cEP which defines our spec and make it stable.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/coala-analyzer/cEPs/issues/11#issuecomment-229310140, or mute the thread https://github.com/notifications/unsubscribe/AFc6KHv6FyDVaqkpsSJHOBd-XOlpw9INks5qQj-HgaJpZM4JA8-f .
For YAML: I believe pyYAML has some kind of safe-mode to prevent these execution problems, though this also limits functionality (but for our case we don't need to care, as we don't need that)
but yes I agree too :D
we have decided on a new format in cEP-0005. There was some discussion and I'm not sure if all the arguments are in there.
https://github.com/coala/cEPs/blob/master/cEP-0005.md
The aspects gsoc projects last year also discussed enhancing the format at https://github.com/coala/coala/issues/4511, but that went nowhere.
Also https://github.com/coala/coala/issues/4609 was created, but I am closing that now as it should be handled here as a cEP modification.