inconsistency in require

[jlaurens]

In l3build.lua we have a local function build_require to require various packages. In l3build-ctan.lua, we have require"l3build-zip". Consider next layout

abc/ abc.dtx
     abc.ins
     build.lua
     l3build-<whatever>.lua
     l3build-zip.lua 
     README.md
     support/
     testfiles/

If you run l3build on this package, the local l3build-zip.lua will replace the global one, but not the other l3build-<whatever>.lua.

3 solutions

1. always use require"l3build-...
2. newzip = build_require"zip" in l3build.lua (another global variable) or l3build.newzip = build_require"zip" in l3build.lua (another global variable, but more friendly)
3. make build_require global or call it l3build.require

solution 1 offers more possibilities.

[josephwright]

@zauguin Thoughts here?

[jlaurens]

One more situation to consider: real life testing. How would you build the various packages in the examples folder? Is it necessary to install the development version of l3build first? Can it be sandboxed?

[zauguin]

• always use require"l3build-...

• newzip = build_require"zip" in l3build.lua (another global variable) or l3build.newzip = build_require"zip" in l3build.lua (another global variable, but more friendly)

• make build_require global or call it l3build.require

Option 4 (which I'm in favor of): Add a searcher to make require'l3build-...' behave the same as build_require`.

I think generally for l3build it's much nicer to always have a consistent set of versions without local replacements. Also this avoids picking up partially installed versions. That shouldn't depend on the call syntax though.

[jlaurens]

@zauguin It seems not a good idea to mimic exactly build_require because actually after build_require'newzip' we have

package.loaded["/usr/texlive/2024/.../l3build-newzip.lua"] == <the new zip function>

whereas after require"l3build-newzip" we have

package.loaded["l3build-newzip"] == <the new zip function>

the latter is closer to lua standards.

Here the searcher would be used for a finite list of subpackages known in advance. The package.preload feature seems a lighter solution for the very same result. In practice, we can list all the l3build-*.lua next to l3build.lua and preload them at that location or in the current directory if any.

Anyways, the searching policy, either used by a searcher or to populate package.preload, should be a bit more general than the actual one to allow the usage of an l3build package that does not yet belong to a distribution (mainly for testing purposes, including testing l3build itself). It means that the replacement of build_require should be consistent with get_script_name in l3build-aux.lua. There is room for a big design improvement here.