Willy, 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 variable. 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 name. Example: 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 documentation. ---- > 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
