Am 09.01.20 um 17:38 schrieb Willy Tarreau:
>> I concede that the HAProxy documentation should mention `package.path`
>> to be clear what kind of path it refers to. But I disagree that we
>> should explain how this works in detail, because this is not about any
>> HAProxy specific stuff, but about the "inner workings" of Lua and thus
>> it's best explained by the Lua documentation. We would only be able to
>> "re-explain" the existing documentation, but probably worse, because we
>> miss out on important details.
> Except that the terminology here is totally misleading. I didn't understand
> your proposed example even when reading the commit message and the proposed
> doc. This solely because Lua uses the term "path" to designate a pattern,
> while in traditional environments a path is more a list of directories.
> *This* must be mentioned. It's not acceptable to have a config documentation
> saying "hehe I caught you, you thought you would find the info you were
> looking for here, but no, please visit this link instead, and too bad for
> you if the net access is down due to haproxy not starting because of the
> wrong config you're trying to fix, have a good night sir". I'm not suggesting
> to paraphrase the Lua's doc, just to mention the few elements that are
> sufficient for someone having to edit an entry to understand what he/she's

Fair enough. Without creating a completely new patch, what about
something like this:


Prepends the given string followed by a semicolon to Lua's package.path

Lua's package.path is a semicolon delimited list of patterns that
specify how the `require` function attempts to find the source file of a
library. Question marks (?) within a pattern will be replaced by module


By specifying the following path:

  lua-prepend-path /usr/share/haproxy-lua/?.lua

Lua will attempt to load the /usr/share/haproxy-lua/example.lua script
when `require "example"` is being called.

See https://www.lua.org/pil/8.1.html for the details within the Lua


> doing. The link is then provided to have the details. And by the way it
> should also be clear what happens if multiple such directives are specified
> (I have no idea).

It prepends multiple times (instead of overriding the to-be-prepended
value). So I suppose it works like you expect it to work. In fact that
was part of the example given in my initial mail. I prepended two
different "paths" and both variants appear in the error message in
addition to the default ones.

Best regards
Tim Düsterhus

Reply via email to