Provide a binary? about l3build HOT 37 CLOSED

For reference, the reason for the current approach was that it is relatively easy to use across platforms and without any particular additions to the TeX system in use. In particular, I'm not sure how one deals with 'local' installs for an executable (can't just go in ~/texmf). On Windows at least there is also a need to have a stub wrapper somewhere to allow the program to run.

from l3build.

Hmm, I see what you mean for local installs. I guess if the wrapper is simple enough then we shouldn't need to change it much; e.g., something like

#!/usr/bin/env texlua

dofile("build.lua")

is ‘enough’ for the dead-simple use case. Anything dealing with new options can still be written as .lua files installed in texmfhome and loaded using the kpse library. I don't know what is needed from the TeX Live / CTAN perspective to indicate a programme to be installed in the bin directory though!

I also hadn't considered the Windows side of things. I suppose that makes the whole effort more difficult...

from l3build.

from l3build.

Yes, for that level of convenience I agree having a separate binary offers little benefit — for me, I think an easier approach is to have a bash alias set up as build='texlua build.lua'.

Any advantage of a binary would be that users don't need to write their own build.lua script to get started. (Assuming this then allows you to write something like l3build init, or even if it just gives instructions when l3build is executed without arguments.)

I know right now it's not hard! But every little bit helps I think.

Additionally, I think it's an easier sell to tell people to just run l3build ctan.

from l3build.

from l3build.

from l3build.

from l3build.

On the requirement for a build.lua, we currently would need it even with a binary to deal with module. That can easily be altered.

If we want to go down the binary route, I'd suggest we talk with the TL people and with Christian Schenk, and get l3build added as a 'first-class' tool. We'll likely need a bit of adjustment of how l3build itself gets released, but that is all doable.

from l3build.

from l3build.

If we want to go for this we should make the decision: it will need some reworking of how existing build.lua files work (both the 'load the core' line and the variable setting will need to change). Should we ask the distro people about how easier it would be for them to add the necessary wrappers?

from l3build.

from l3build.

@davidcarlisle At least in TeX Live it's a wrapper .exe file: I suspect that is true for MiKTeX too and for all scripts: Windows needs something that is a 'real' executable stub. It's all set up easily enough, just needs some help from the system maintainers.

from l3build.

The biggest single issue would be that we'd need a new scriptfiles table as we'd need to put the script parts in a different place to the TeX part. All doable (as usual).

Overall, this might well be a good idea now we are getting wider take-up of l3build. I think we probably should raise it with the TL team and Christian Schenk, and agree on when to make the change. There will be a bit of re-working of the way we do over-riding of functions, which will be the most 'interesting' part (basically the entire logic has to get flipped).

from l3build.

I notice that kpsewhich finds stuff in scripts, so we will be fine moving and having a 'transition', and also allowing local installation.

from l3build.

Unless I hear otherwise, I'll start on this shortly, probably first by adjusting where the script installs to, then branching for a version that is intended to run directly not by running the build.lua script (so for testing texlua l3build.lua <target> until we have a script runner).

from l3build.

@josephwright — does the logic have to change or do you just think it's a good time to streamline things?

I was thinking more that you might have something like l3build-binary.lua which is the basis for the l3build executable; it might do its own argument parsing for a few small steps but then has something like

build_file = <arg parse> or "build.lua"
dofile(build_file)

and then everything continues as it currently does. Is that too clunky, do you think?

from l3build.

@wspr The problem there is that current build.lua files end with lines to load l3build: I think we'd end up with issues avoiding double-loading, etc.

We also gain an opportunity to tidy up some of the load order stuff with a binary: it loads first so we get l3build (bulk) then build.lua then (at the end of l3build) fire main(). That means that the build.lua file can rely on functions being defined when it loads, so it would address e.g. the issues you've had with the manifest target. That wouldn't work if you try 'both routes'.

More widely, I guess I'd like a single approach. Looking at the needs for a binary, they are actually pretty small. So we could make everyone's life easier and be able to do

l3build check -epdftex

or similar 'universally'. Would be good learning experience for any future format (where a ConTeXt-like sctipt is I think a must).

from l3build.

@josephwright — not complaints from me on a reordering of the loading order and so on; I just wanted to make sure. I agree it makes life easier for certain parts of the code.

Good point about the ConTeXt-like script! I would always want a default "just run it once", I think, but it make sense to build support in for code to indicate when it needs a re-compile, with a matching tool to make it all happen.

from l3build.

from l3build.

@FrankMittelbach To be clear, a binary here is only needed for Windows and is a stub: what we are really talking about is allowing l3build.lua to be a script run directly rather than needing texlua <some name>. The suggested change would still allow

texlua l3build.lua

with the biggest actual alteration being that you then have a fixed name for the config script (more like make).

from l3build.

Having just started a few new projects I now see a different "need" for the binary (already mentioned in @wspr original issue): the ability to start a project without the need to write a build.lua first, eg

l3build --name "Frank Mittelbach" 
        --mail [email protected]
        --license lppl
        --type simple-flat
        --...  (other CL args, eg looks at dtxgen or sty2dtx)
        <module-name>

most of the args could be default, eg mail and name could be $MAIL and $NAME if set, license could default to lppl, etc

This way one could get with a single line a while template structure being build with basic test files, .ins file proper license info etc etc

I think this would be really valuable.

from l3build.

@FrankMittelbach OK, as we are in the TL freeze period we have a window to do this: I'll action.

from l3build.

The core actions required here are:

• Move installation target to scripts: probably use a new scriptfiles value for this (will support others)
• Adjust the loading to allow direct calls to the script and to auto-run a build.lua file
• Change --version to --tag (see #40)
• Add some basic form of manpage data (requested by Karl Berry)

from l3build.

looks good to me

from l3build.

I'll probably branch for all of this: I'd rather have somewhere 'safe' to work on the changes.

Two areas to note on build.lua. First, I think we can pick up both current and 'new' usage (so texlua build.lua versus texlua l3build or just l3build. Second, I think it makes sense to load build.lua 'late' such that it can access globals (see @wspr's issues setting up manfest). To do that, I'll arrange to read l3build-variables.lua twice: once 'early' to set up the global names, then again after reading build.lua. Fingers-crossed this will keep the current behaviours but also allow better set ups for other stuff.

from l3build.

from l3build.

@FrankMittelbach I was thinking you'd have l3build init --<setup-options>, i.e. one always needs a <goal> for something to happen.

from l3build.

yes right you are, but that makes it even simpler I guess (except that init should balk if there is already a structure of some sort)

from l3build.

The first two points of my list are done: they are by far the most important. I think everything still works: could some other people check?

Are we happy sticking with a hard-coded config name of build.lua. I note that things like make use a fixed name: I suspect we are fine but at least want to check. (We have the --config option but that's really meant for something subtly different, though doubtless we use it as an override if required.)

from l3build.

from l3build.

@FrankMittelbach On 'how will this work', we are in a 'flux' state just at the moment. If you run texlua l3build.lua for l3build itself, you will get the new interface. If you install it then do texlua build.lua <target> for say LaTeX2e it will also pick up the new script as that old build.lua construct has the lookup stuff. The only place you have to do a manual lookup is with a new-style build.lua for cases other than l3build itself. Once I upload to CTAN and Karl/Christian install the new code, the script will be directly callable using just l3build <target>, as for other Lua scripts (e.g. lwarpmk). That work (I think) on *nix by having a symlink from <texmf>/bin/<name> to <texmf>/texmf-dist/scripts/<name>. I'm not sure about 'local' installs (one might have to fiddle about a bit with symlinks), but for the bulk of users that will be fine. ('local' installs are really just an issue for the team.)

On the build/ directory, we could just change the standard name to say tmp/.

from l3build.

from l3build.

I think we are good to go: just need a man page (so we can do a prerelease already). If everything looks OK I'll merge.

from l3build.

can't see why not (after understanding why it didn't work here due to version mixup in the local tree)

from l3build.

Everything should now be in place: I'll get to CTAN to see what issues come up in pre-testing.

Probably we want to set a sunset period for the older approach: various bits of the code can be simplified if we don't need to support loading build.lua 'early'.

from l3build.

from l3build.

Sure: was thinking at least a year. I mainly wanted to flag up that there are reasons we might want to consider this longer-term.

from l3build.