replace our lua parser with lupa?

[DanAlbert]

#316 was needed to work around a parsing error in a new livery in today's update.

I also fixed about a dozen other parser errors the other week. Should we just take the dependency on lupa, continuing to squash bugs in our own parser as they come up? Worth mentioning that even with lupa we won't be bulletproof, since parsing can easily be broken by DCS deciding to change the format or even just doing things like name = identity("foo") (though if we had lupa we would at least be able to evaluate those, but we'd need to do so proactively).

@rp-, it's your call. My opinion doesn't count for much because adding lupa would be a hardly noticeable change for liberation, but might be for smaller projects.

[rp-]

I think my reasoning against lupa back than, was introducing that dependency.
And at first it was just about parsing the relative simple .miz "lua" format.

I guess since we introduced pyproj, there is not much reasoning against another bigger dependency like this.

[DanAlbert]

Yeah, when it's just the Miz we can get away with a lot less since we only have to cope with whatever the ME produces. For liveries and a handful of other things we may want to parse where they're hand written we'd actually need a complete parser :)

I'm not sure if I'm going to look into this any time soon, but that's the plan I'll go with next time something breaks, or if I decide I want access to those few liveries that we can't currently parse.

[Maintenance-Partnership-Systems]

Just to add support for this suggestion - I found this issue because I was diagnosing a crash in Liberation when loading custom liveries. The cause was the use of [[ ... ]] quoted strings for the file paths in the description.lua, and the home-grown parser doesn't handle that. A general-purpose parser might be more likely able to handle unusual cases like this.