-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
...
is not populated when tl run
loads a Lua module
#689
Comments
@fperrad Is this behavior documented? I tried to find it in the Lua manual but I must have missed it. I am in favor of implementing, but ideally I would like to follow the documentation to ensure I got the behavior right. |
quoted from https://www.lua.org/manual/5.4/manual.html#pdf-require
|
Instead of hardcoding the arguments within the loader, pass them through the searcher, as specified by the documented behavior: #689 (comment) > quoted from https://www.lua.org/manual/5.4/manual.html#pdf-require > >> Once a loader is found, require calls the loader with two arguments: >> modname and an extra value, a loader data, also returned by the >> searcher. The loader data can be any value useful to the module; >> for the default searchers, it indicates where the loader was found. >> (For instance, if the loader came from a file, this extra value is >> the file path.) Thanks @fperrad for the research!
Instead of hardcoding the arguments within the loader, pass them through the searcher, as specified by the documented behavior: #689 (comment) > quoted from https://www.lua.org/manual/5.4/manual.html#pdf-require > >> Once a loader is found, require calls the loader with two arguments: >> modname and an extra value, a loader data, also returned by the >> searcher. The loader data can be any value useful to the module; >> for the default searchers, it indicates where the loader was found. >> (For instance, if the loader came from a file, this extra value is >> the file path.) Thanks @fperrad for the research!
Instead of hardcoding the arguments within the loader, pass them through the searcher, as specified by the documented behavior: #689 (comment) > quoted from https://www.lua.org/manual/5.4/manual.html#pdf-require > >> Once a loader is found, require calls the loader with two arguments: >> modname and an extra value, a loader data, also returned by the >> searcher. The loader data can be any value useful to the module; >> for the default searchers, it indicates where the loader was found. >> (For instance, if the loader came from a file, this extra value is >> the file path.) Thanks @fperrad for the research!
* fix: populate `...` for required modules Fixes #689. * adjust code to more closely match documented semantics Instead of hardcoding the arguments within the loader, pass them through the searcher, as specified by the documented behavior: #689 (comment) > quoted from https://www.lua.org/manual/5.4/manual.html#pdf-require > >> Once a loader is found, require calls the loader with two arguments: >> modname and an extra value, a loader data, also returned by the >> searcher. The loader data can be any value useful to the module; >> for the default searchers, it indicates where the loader was found. >> (For instance, if the loader came from a file, this extra value is >> the file path.) Thanks @fperrad for the research! * loader args: provide consistent behavior across Lua versions This implements a compromise solution that allows Teal modules to always get both arguments, even in Lua 5.1 based systems (this should be harmless for modules which don't expect a second argument there), without hardcoding `loader_data`, just in case the user is on an environment that runs a patched `require` for debug reasons or something.
The text was updated successfully, but these errors were encountered: