Yes, we have a `lux-lua` library (which we will need to bundle with `lux-cli`) that exposes a `lux.loader` module. It uses the lockfile to resolve dependencies.
With Lua, it becomes near impossible for a program like lux to edit the manifest.
For example, how would I `lx add <dependency@version>` if the `dependencies` table might be generated by a Lua function?
Lux defaults to TOML, but if you really want Lua, it also supports an `extra.rockspec` in the project root, which shares the same format as the luarocks RockSpec format.
The function would be "compile time" so that function would be evaluated when you call `lx add <dependency@version>`, I'd also assume that the previous configuration would be cached and a diff shown of dependencies.
But I would also accept that it would be a subset of Lua that could define tables, but not contain functions. The data only declarative sublanguage.
> - Yes, it also works with LuaJIT, either via pkg-config or by installing LuaJIT headers using the `luajit_src` crate.
Are there any documentation on this?
luarocks works with luajit after I run that specific command, I expect something like that as it is very easy, so I wonder if running "lx path bin" would work.
That's a neat suggestion, thanks.
Lux will need some time to become mature, but building a large multi-platform project like koreader would definitely be a nice goal.
With the disclaimer that I know nothing about zig, I will say that Nix's flake files follow an interesting pattern where the output section is evaluated under the regular Nix interpreter and can do anything, whereas the input section is evaluated under a far stricter mini-interpreter that prohibits everything other than basic strings and attrsets (dictionaries).
A flake.nix is certainly not packaging metadata, but I do know those input section restrictions do cause occasional confusion with users who think "ah, Nix code" and only realise afterward that it's really json in Nix syntax."
All that to say, if a thing is not evaluate-able, it's probably best to represent it in a different enough form that no one could mistake it for a thing that can be evaluated.
Why not use a function to add dependencies, e.g. `add_dependency "dependency@version"` or `add_dependencies { ...table-here... }`. This is, more or less, how premake works [1]. For `lx add ...` you'd append the function call to the script.
