2

Say I want to write a patch for one or some of the expl3 modules. As far as I can see, to test the patch I have to do the following:

  1. Edit the module's .dtx file;
  2. Run l3.ins to compile (beside others) expl3-code.tex from all l3kernel modules;
  3. Include package expl3 from my main testing document.

For writing more complex patches that require you to repeatedly edit and test your code, this is tedious and impractical.

Ideally, I'd like to directly modify a .dtx file and include only that updated package into the main file. As expl3 seems to include all packages, that won't work; including a separate package afterwards would cause errors because of duplicated definitions. (My first problem here is already how to properly create the .sty file from the .dtx file.)

So my questions:

  1. Is there a way to selectively import expl3 packages on top of the already loaded ones, or prepare a special version of expl3 that will pull in the code from individual .sty files instead of one big kernel dump?

  2. What is the workflow of active LaTeX3 developers? Do you have special building scripts or tools?

  3. Are there other debugging options or tools (especially for the expl3 packages) one should be aware of other that the few commands mentioned in interface3.pdf?

Improve this question
3
  • Just a stupid comment: if you are redefining an already existing macro from the kernel you can use the gset variant instead of new, then no verification whatsoever will be done and you can load your patch afterwards as a package. Then, after you're done, you can patch-in those changes to your copy of the sources and build it normally. Commented Jun 10, 2019 at 17:49
  • 2
    I run l3build install to install the files in a special texmf, for only l3kernel that's reasonable fast. But why are you changing the original dtx-files from expl3? Do you plan a pull request? Commented Jun 10, 2019 at 17:50
  • Yes, the point it to prepare patches that might actually go into the development version. So using gset is no alternative. Commented Jun 10, 2019 at 17:52

1 Answer 1

Reset to default
3

Historically, we did load all of the .sty files separately, but the load order requirements made that tedious. Having each .sty separately was all a recipe for issues with mismatched versions. As such, we have moved to a single file. The reason is in part that expl3 itself is quite stable, so the number of changes to it are normally limited.

For work on expl3, I use one of two workflows, depending on the detail. For simple changes, I just set up a test document which contains the code I want using gset rather than new. I test it 'locally', then copy back to the sources and make the adjustments needed. As it will need to pass the test suite anyway, that is normally fine.

The alternative, for bigger changes, is simply to alter the .dtx files and do an install to put it into my local tree, then again to run some 'local' tests. That is done using l3build. Once again, we need tests before adding new code, so there is always that to do.

Improve this answer
2
  • Worth bearing in mind that the team also sort the format, where there really is no option but to install-and-build. So our workflow is based on having some non-trivial build set up most of the time. Commented Jun 10, 2019 at 18:28
  • I'm also not sure there is much difference between running DocStrip on a large set of files and running it just on one: it's quite a fast process. Commented Jun 11, 2019 at 9:12

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.