Changes to Capirca to allow for additional policy parsers.
- Dominant language
- Python
- Stars
- 857
- Forks
- 213
- PR merge metrics
- No merged PRs in 30d
Description
Capirca has historically only ever had the ply parsers but there is active work on a yaml parser. I would like to take some time to solicit opinions on how we should approach the inclusion of other parsers, their interaction with policy.py, and the rest of Capirca. The following are a couple of ideas suggested by people but I invite others to propose their own and discuss their opinions on each.
1) Policy.py is passed data and in turn sends these to the correct parser. The parser is required to send back some data structure like a dict. Policy.py will use this to then use this structure to build the policy object.
2) Have additional parsers convert to a pol format string which is then fed into policy.py. This could be done with a templating system or something else.
My thoughts are that option 2 is the best choice. It has been pointed out that by having multiple parsers there are chances for equivalent policies to be constructed differently resulting is disparate syntax files. It would also require less manipulation of policy.py.
The only problem with this choice is it ends up further ingraining the lexx/yacc into things. If I was to rewrite Capirca today I would most likely not choose lexx/yacc but opt for some simpler format. I don't know if others have ever tried adding new keywords to the parser but I find it to be a hassle. This may be a non issue though as I have not seen any demand for new additions to terms in a while.
Anyway, please feel free to comment on your opinions if you feel strongly one way or the other.
Contributor guide
Assessment
This issue has not been assessed yet.