up vote 10 down vote favorite

I notice that no packages on ctan include build.lua scripts, which would enable them to be installed using l3build.

I find it is now easier to build and install a package using l3build than manually processing the ins and dtx files and copying the derived files and documentation to the right locations.

So why don't we include the build.lua file in the ctan zip file?

(I know that most people would just wait until a package is in their distribution to install it. I'm just curious.)

share|improve this question
  • 3
    Presumably because noone else than the latex team uses or knows about them, plus they want users to update using the managers, hardly anyone updates by hand anymore – daleif Oct 18 at 6:07
up vote 11 down vote accepted

There is nothing to stop you including build scripts in CTAN uploads: for example, in the past beamer used to have the Makefile on CTAN. However, a build script is not part of the package itself:, but is rather a convenience for the developer. (In the end, one can always extract a package and create documentation by hand.) Most notably, it's not usual to upload other 'support' material to CTAN, in particular test files, which are also part of the 'developer' files.

One can argue about the 'philosophical' aim of CTAN, but broadly it's always been about files for users. Additional material for developers has never really gone there. (For example, the sources for pdfTeX, etc., are not on CTAN.) Historically, users would take a .dtx/ins pair to install a package: today, almost all of them use TeX Live/MiKTeX, neither of which want build scripts. The small number of 'self-installing' users either are familiar with the classical route, or can be supported by a TDS-style zip for more complex packages.

Almost all code being actively developed has some kind of public source control nowadays. The type of user who is comfortable using a build script for a 'local install' is probably comfortable with a Git or SVN checkout, too. That lets them get the latest code, not necessarily what CTAN holds, in any case.

share|improve this answer
  • That makes sense. I think I have seen .dtx and .ins files more like source files than user files. So this causes me to see CTAN more like a centralised source repository and TeXLive/MikTek as binary repositories. There's no tools to install directly from CTAN like there is from CPAN, for example. But this is, as you note, a question of the philosophical aim of CTAN. The way CTAN functions now seems to be mainly as a single submission point for TeXLive and MikTek (which is useful), but it advertises itself as a place were 'pack­ages are free and can be down­loaded and used im­me­di­ately.' – David Purton Oct 18 at 9:16
  • @DavidPurton Well there's a mix of history and technical aspects. CTAN was set up very much as an archive for manual installation by knowledgable users, but really only for the macro package part of the TeX 'universe'. At the same time, TeX itself can't download/install stuff: that's a big contrast to Perl, which can. So we've got very different history in terms of what is expected. Lua scripting makes a difference, but I doubt we'll ever see direct CTAN installation. – Joseph Wright♦ Oct 18 at 9:26
up vote 12 down vote

As Joseph writes build.lua and makefiles are for the development and not for CTAN (and I just removed the makefiles from the luaotfload upload for this reason). They can contain code and settings which are not suitable for a normal user installation like the call to local tools, or specific locations.

As an example in the build.lua of the lualibs package the install target "installs" the files in the repository of luaotfload. This makes it easy for me to run the online tests for luaotfload with synched lualibs files. It would be rather a pain to have to restrict the content of the build.lua to settings which makes sense in a normal user setup.

share|improve this answer
  • I'd probably have lualibs as a dependency from the luaotfload 'side', but the same basic issue of course would come up (unless like LaTeX3 everything is in one big repo). – Joseph Wright♦ Oct 18 at 8:25
  • @JosephWright you mean with submodules? I used that when I needed some of the experimental stuff from the lua-font-pond in other repositories but I do find them more difficult to manage for something simple as copying around 20 files to another folder. – Ulrike Fischer Oct 18 at 8:31
  • No, I was thinking just having the two repos checked out in a known relationship (probably both in the same directory), then doing something like checkdeps = maindir .. "../lualibs" or similar. A bit like we do for l3kernel with xparse or whatever, but using two separate repos. – Joseph Wright♦ Oct 18 at 8:35
  • Not quite that I get you. How do one tell travis about this? – Ulrike Fischer Oct 18 at 8:37
  • I'd use the before_install: hook to clone the dependency, so something like before_install: git clone https://github.com/lualatex/lualibs.git. That would clone into the same parent dir as the luaotfload one, so would have the same relative layout as you can have one your own machine. There might be a bit more to it, but broadly it should work. – Joseph Wright♦ Oct 18 at 8:51
up vote 8 down vote

Most l3build scripts are somewhat tied to the test framework and usually test files are not shipped to ctan. Anyone who wants to install via l3build would most likely be better served by getting from a source repository such as GitHub rather than ctan. "waiting" for a ctan upload to reach texlive is usually only a day or so, so basically no one should be installing files from Ctan.

share|improve this answer

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.