> On 9 Jan 2020, at 22:02, Willy Tarreau <[email protected]> wrote: > > On Thu, Jan 09, 2020 at 08:22:29PM +0100, Tim D�sterhus wrote: >> Bob, >> >> Am 09.01.20 um 19:44 schrieb Zakharychev, Bob: >>> I'd say that since the issue can be solved naturally and completely within >>> the confines of Lua itself, new parameters should not be introduced in >>> HAProxy to give one ability to solve it differently while obscuring the >>> solution in configuration of the host program, however tempting this might >>> look. >> >> To put my POV into a different perspective: HAProxy is the host program >> of the Lua scripts and thus it is responsible for providing a working >> environment to the script. It should not need to know how the file >> system layout works. >> Configuring this environment within HAProxy just feels natural even if >> it might be possible to configure this setting from within a dedicated >> "configuration script" as well. > > The useful point I'm seeing here is that it allows users to use some > external Lua programs with no modification and only specify the paths > in the global section which centralizes everything specific to the > deployment. Also it even allows to use environment variables there, > which can be quite useful. > > However, Bob, your concern confirms mine about the risks involved by > adding the ability to execute some Lua code inlined directly from the > haproxy config. So I think that if we want to stay reasonable, at least > for a while, we should take Tim's patch as it is now to help configure > the path, but not put Lua code in the config file.
Hi guys, I don’t have any opinion about this. But I extend the problem: There are not only package.path, but also package.cpath which provides default location for .so libraries. https://www.lua.org/manual/5.3/manual.html#pdf-package.cpath Thierry
