[RFC] stand/lua: Bring in local.lua module if it exists

[kevans]

Summary

I think this is the way we want to do this.

Provide a way for out-of-tree users of lualoader to patch into the loader system without having to modify our distributed scripts.

This is not a catch-all. There are some (very few) things that happen when our modules are loaded. I think we will need to provide hooks to modify or completely override these behaviors as we introduce them, unless they're something that can easily be overwritten (e.g. core will set a default ACPI setting on import).

We'll also need to rewrite other things to be a little more friendly to other consumers, such as how the menu system processes menu entries. These should probably be setup as a table of entry type => processor functions so that out-of-tree consumers can trivially add their own menu types or alter behavior if they want different behaviors. This obviously applies to menu drawing as well.

[kevans]

I think we'd also need to make it pretty clear what we'd consider ABI in lua, or maybe do a better job of exposing a minimal set of things from each of the modules that we export.

[cem]

What's the goal here? What kind of things do we imagine local lua code hooking into? I'm having trouble imagining something that wants to use this instead of just forking all of stand/lua for their own ends.

(Put another way: usually we try and create APIs to meet a need. That need can be out of tree, but something should use it.)

[kevans]

In D14439#302787, @cem wrote:

What's the goal here? What kind of things do we imagine local lua code hooking into? I'm having trouble imagining something that wants to use this instead of just forking all of stand/lua for their own ends.

I imagine it being used for lighter use cases that shouldn't require a full-blown fork. Things like adding new logos and brands (now trivial modifications to drawer.logodefs/branddefs) or adding appliance-specific menus

Cosmetic changes more-so than functional changes, because maintaining a fork can sometimes be quite irritating.

[cem]

In D14439#302788, @kevans wrote:

I imagine it being used for lighter use cases that shouldn't require a full-blown fork. Things like adding new logos and brands (now trivial modifications to drawer.logodefs/branddefs) or adding appliance-specific menus

Cosmetic changes more-so than functional changes, because maintaining a fork can sometimes be quite irritating.

Ok. I would lean very strongly away from offering any API compatibility promises at this time. We can mark/document stable APIs as needs are brought up. Until then, this is an active component under a lot of churn and it doesn't make sense to guarantee APIs no one uses that we may want to change shortly.

stand/lua/loader.lua

32

So lfs.attributes() is kind of weird. In the stat(2) error case it returns a 3-tuple: (nil, "error string", errno_integer). But if it succeeds it just returns the result table, and if the user passed something that wasn't a string for the path argument, it just returns nil.

It turns out Lua will just use the first returned value in expressions like the ~= comparison above, so we're fine with the code as-is. And probably we don't care about the error reason.

So for reference, a full attributes invocation looks like:

result, errstr, error = lfs.attributes(…);
if result == nil then
    -- maybe errstr/error aren't nil, but if they are we passed a bogus path object
    -- otherwise, maybe the errstr/error are interesting
end

I think it's a little odd that the first kind of error doesn't return the same kind of string and errno as stat(2) errors, so maybe that's something to change in lfs.