Willy, Am 14.01.20 um 14:53 schrieb Willy Tarreau: > On Tue, Jan 14, 2020 at 02:04:04PM +0100, Thierry Fournier wrote: >> Idea 1: >> >> lua-prepend-path path /etc/haproxy/lua-modules/?.lua >> lua-prepend-path cpath /etc/haproxy/lua-cmodules/?.lua >> >> Idea 2: >> >> lua-prepend-path /etc/haproxy/lua-modules/?.lua >> lua-prepend-path cpath /etc/haproxy/lua-cmodules/?.lua >> >> Idea 3: >> >> lua-prepend-path /etc/haproxy/lua-modules/?.lua >> lua-prepend-cpath /etc/haproxy/lua-cmodules/?.lua > > I guess the third one is better, at least for a reason which is that > it causes less confusion when asking a bug reporter "what's in your > lua-prepend-path ?". We've seen sufficient confusion from the maxconn > word being used for different tihngs depending on where it's set, so > we'd rather keep this clear.
Let me give my reasoning for my choice: - I wanted to avoid two completely distinct configuration options for what is essentially the same thing. It would require adding both to the documentation. - I made the type optional, because I expect the majority of modules loaded via this option to be pure Lua modules. The path is meant to be the home of HAProxy specific modules. I consider it unlikely for an user to develop a C based Lua module that is HAProxy specific when they can simply use a regular C based HAProxy module without corkscrewing it through Lua. Stuff such as cjson would be put into the system wide Lua path and thus be available to every Lua script including HAProxy, because it sits in the default path that is compiled into the Lua VM. - I put the type last, because I consider optional parameters that are in the middle to be unintuitive and it complicates parsing, because a single index might either be the type or the path if the type is not given. However I don't particularly care for any of this. If you feel like we should to lua-prepend-path and lua-prepend-cpath instead then I'm happy to adjust the patch (or you do it). Best regards Tim Düsterhus
