install modules in a Docker container
I’ve not much experience with Docker and tried the context:lmtx container from Island of TeX. It downloads quickly and works well. But I need some additional modules. Installation with mtxrun seems to work, but ConTeXt can’t find the module afterwards. I’d guess that’s a Docker problem? Here’s the Dockerfile: FROM registry.gitlab.com/islandoftex/images/context:lmtx ENV TZ=Europe/Berlin USER root RUN apt update RUN apt-get install fonts-liberation fontconfig RUN fc-cache -f RUN cd /context/tex && mtxrun --script install-modules --install statistical-charts,tikz RUN mtxrun --generate RUN mtxrun --script fonts --reload --force USER jenkins Hraban
Hi Hraban, On Mon, 2025-11-17 at 12:53 +0100, Henning Hraban Ramm wrote:
I’ve not much experience with Docker and tried the context:lmtx container from Island of TeX. It downloads quickly and works well.
[...]
FROM registry.gitlab.com/islandoftex/images/context:lmtx
That image is deprecated https://gitlab.com/islandoftex/images/context#context-docker-image in favour of registry.gitlab.com/islandoftex/images/texlive/texlive:context
But I need some additional modules.
The "texlive/texlive:context" should include every ConTeXt module available in TeX Live. If there are any modules missing, that's probably a bug in my packaging scripts https://github.com/gucci-on-fleek/context-packaging Thanks, -- Max
Am 17.11.25 um 13:46 schrieb Max Chernoff via ntg-context:
FROM registry.gitlab.com/islandoftex/images/context:lmtx
That image is deprecated
https://gitlab.com/islandoftex/images/context#context-docker-image
in favour of
registry.gitlab.com/islandoftex/images/texlive/texlive:context
The "texlive/texlive:context" should include every ConTeXt module available in TeX Live. Ok, thank you! Since it works with the texlive:current container, I trust it will also work with texlive:context (can only check tomorrow).
Hraban
Am 17.11.25 um 20:03 schrieb Henning Hraban Ramm:
Am 17.11.25 um 13:46 schrieb Max Chernoff via ntg-context:
FROM registry.gitlab.com/islandoftex/images/context:lmtx
That image is deprecated
https://gitlab.com/islandoftex/images/context#context-docker-image
in favour of
registry.gitlab.com/islandoftex/images/texlive/texlive:context
The "texlive/texlive:context" should include every ConTeXt module available in TeX Live. Ok, thank you! Since it works with the texlive:current container, I trust it will also work with texlive:context (can only check tomorrow).
Unfortunately, it didn’t, the container was not found. The website also only hints at the old images. Hraban
Hi Hraban, On Tue, 2025-11-18 at 20:13 +0100, Henning Hraban Ramm wrote:
Am 17.11.25 um 20:03 schrieb Henning Hraban Ramm:
Am 17.11.25 um 13:46 schrieb Max Chernoff via ntg-context:
The "texlive/texlive:context" should include every ConTeXt module available in TeX Live. Ok, thank you! Since it works with the texlive:current container, I trust it will also work with texlive:context (can only check tomorrow).
Unfortunately, it didn’t, the container was not found.
Sorry, it looks like I gave you the wrong tag name. You want texlive:latest-context instead. I've included a full list of all the ConTeXt-related tags at the end of the email. Thanks, -- Max $ skopeo inspect docker://registry.gitlab.com/islandoftex/images/texlive | jq --raw-output .RepoTags[] | grep -i context TL2025-2025-07-17-context TL2025-2025-07-17-context-doc TL2025-2025-07-17-context-doc-src TL2025-2025-07-17-context-src TL2025-2025-07-20-context TL2025-2025-07-20-context-doc TL2025-2025-07-20-context-doc-src TL2025-2025-07-20-context-src TL2025-2025-07-27-context TL2025-2025-07-27-context-doc TL2025-2025-07-27-context-doc-src TL2025-2025-07-27-context-src TL2025-2025-08-03-context TL2025-2025-08-03-context-doc TL2025-2025-08-03-context-doc-src TL2025-2025-08-03-context-src TL2025-2025-08-10-context TL2025-2025-08-10-context-doc TL2025-2025-08-10-context-doc-src TL2025-2025-08-10-context-src TL2025-2025-08-17-context TL2025-2025-08-17-context-doc TL2025-2025-08-17-context-doc-src TL2025-2025-08-17-context-src TL2025-2025-08-24-context TL2025-2025-08-24-context-doc TL2025-2025-08-24-context-doc-src TL2025-2025-08-24-context-src TL2025-2025-08-31-context TL2025-2025-08-31-context-doc TL2025-2025-08-31-context-doc-src TL2025-2025-08-31-context-src TL2025-2025-09-07-context TL2025-2025-09-07-context-doc TL2025-2025-09-07-context-doc-src TL2025-2025-09-07-context-src TL2025-2025-09-14-context TL2025-2025-09-14-context-doc TL2025-2025-09-14-context-doc-src TL2025-2025-09-14-context-src TL2025-2025-09-21-context TL2025-2025-09-21-context-doc TL2025-2025-09-21-context-doc-src TL2025-2025-09-21-context-src TL2025-2025-09-28-context TL2025-2025-09-28-context-doc TL2025-2025-09-28-context-doc-src TL2025-2025-09-28-context-src TL2025-2025-10-05-context TL2025-2025-10-05-context-doc TL2025-2025-10-05-context-doc-src TL2025-2025-10-05-context-src TL2025-2025-10-12-context TL2025-2025-10-12-context-doc TL2025-2025-10-12-context-doc-src TL2025-2025-10-12-context-src TL2025-2025-10-19-context TL2025-2025-10-19-context-doc TL2025-2025-10-19-context-doc-src TL2025-2025-10-19-context-src TL2025-2025-10-26-context TL2025-2025-10-26-context-doc TL2025-2025-10-26-context-doc-src TL2025-2025-10-26-context-src TL2025-2025-11-02-context TL2025-2025-11-02-context-doc TL2025-2025-11-02-context-doc-src TL2025-2025-11-02-context-src TL2025-2025-11-09-context TL2025-2025-11-09-context-doc TL2025-2025-11-09-context-doc-src TL2025-2025-11-09-context-src TL2025-2025-11-16-context TL2025-2025-11-16-context-doc TL2025-2025-11-16-context-doc-src TL2025-2025-11-16-context-src latest-context latest-context-doc latest-context-doc-src latest-context-src
Am 19.11.25 um 02:16 schrieb Max Chernoff via ntg-context:
Hi Hraban,
Unfortunately, it didn’t, the container was not found.
Sorry, it looks like I gave you the wrong tag name. You want
texlive:latest-context
instead. I've included a full list of all the ConTeXt-related tags at the end of the email.
Thank you! Now it works. Hraban
KeenWrite has an automated installation of ConTeXt in a podman container.
The source code for the Containerfile is at:
https://repo.autonoma.ca/?action=blob&repo=keenwrite.git&hash=e23a2a0f03894070ff01472d36dc133285c39120&name=Containerfile
Fonts aside, this produces a fairly minimal installation. There's an "rm
-rf modules" in the file that you'll need to remove to keep the modules
intact. May need to add a few other commands to add specific modules. It
also grabs free fonts from https://fonts.keenwrite.com, so you'll probably
want to change that.
Cheers!
On Wed, Nov 19, 2025 at 2:09 AM Henning Hraban Ramm
Am 19.11.25 um 02:16 schrieb Max Chernoff via ntg-context:
Hi Hraban,
Unfortunately, it didn’t, the container was not found.
Sorry, it looks like I gave you the wrong tag name. You want
texlive:latest-context
instead. I've included a full list of all the ConTeXt-related tags at the end of the email.
Thank you! Now it works.
Hraban
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror) archive : https://github.com/contextgarden/context wiki : https://wiki.contextgarden.net
___________________________________________________________________________________
Just as a reminder, there are already instructions for installing ConTeXt into a Docker container on the Wiki. No need to hack the Keenwrite version. https://wiki.contextgarden.net/Installing_ConTeXt_LMTX_into_a_Docker_contain... Regards,
On 24 Nov 2025, at 03:28, Thangalin
wrote: KeenWrite has an automated installation of ConTeXt in a podman container. The source code for the Containerfile is at:
Fonts aside, this produces a fairly minimal installation. There's an "rm -rf modules" in the file that you'll need to remove to keep the modules intact. May need to add a few other commands to add specific modules. It also grabs free fonts from https://fonts.keenwrite.com, so you'll probably want to change that.
Cheers!
— Bruce Horrocks Hampshire, UK
Am 24.11.25 um 19:16 schrieb Bruce Horrocks:
Just as a reminder, there are already instructions for installing ConTeXt into a Docker container on the Wiki. No need to hack the Keenwrite version.
https://wiki.contextgarden.net/Installing_ConTeXt_LMTX_into_a_Docker_contain...
But it’s still easier to use one of the containers provided by Island of TeX. Hraban
Just as a reminder, there are already instructions for installing ConTeXt into a Docker container on the Wiki. No need to hack the Keenwrite version.
< https://wiki.contextgarden.net/Installing_ConTeXt_LMTX_into_a_Docker_contain...
Some possible issues with the container code on that page: * Inkscape isn't installed, so SVG files may not fully work in all cases. * The base image (debian:latest) has a far larger footprint than needed (alpine:latest is minimal). * Lots of files remain that are not needed, bloating the image more than necessary (e.g., PDF docs). * No extra fonts are installed, so users may have to modify the container anyway to add those fonts. * Certificates may not be up to date. * May be helpful to set OSFONTDIR. * Relies on Docker (and Docker names), which isn't free on all platforms; podman is free on all systems. * Nit: Hard-coded references to "linux-64" could use a variable, instead. Cheers!
Hi Thangalin, Some thoughts on your comments below:
On 25 Nov 2025, at 19:48, Thangalin
wrote: Just as a reminder, there are already instructions for installing ConTeXt into a Docker container on the Wiki. No need to hack the Keenwrite version.
https://wiki.contextgarden.net/Installing_ConTeXt_LMTX_into_a_Docker_contain...
Some possible issues with the container code on that page:
* Inkscape isn't installed, so SVG files may not fully work in all cases.
Fair point, I can see if I can add that.
* The base image (debian:latest) has a far larger footprint than needed (alpine:latest is minimal).
I think, at the time, there was no MUSL version of ConTeXt so Alpine couldn't be used. It can be swapped but unless someone is planning to run a vast swarm of ConTeXt containers the image size isn't really an issue. (And if they are they'll already know how to reduce it.)
* Lots of files remain that are not needed, bloating the image more than necessary (e.g., PDF docs).
Not sure what you mean here. The ConTeXt PDF documentation is retained because it's part of the distribution.
* No extra fonts are installed, so users may have to modify the container anyway to add those fonts.
There's no way to know what fonts people might want, so maybe some commented-out lines could be included as an example to show people how to add a font but it wouldn't get added by default.
* Certificates may not be up to date.
ConTeXt doesn't use any certificates, afaik. If the installer uses tools such as 'curl' and they use certificates then the base OS container takes care of it.
* May be helpful to set OSFONTDIR.
I didn't need it when I was testing the container but might be needed if additional fonts are added.
* Relies on Docker (and Docker names), which isn't free on all platforms; podman is free on all systems.
I'm not sure what the issue is here. The page uses standard Docker terminology so that it will build on a Docker installation. If someone wishes to use podman or Orbstack or one of the several other container build/runtime environments available instead then they are expected to consult the documentation that comes with their preferred system to understand what changes need to be made. Sticking to standard terminology makes that simpler. (Or, put another way, if you replaced the wiki page with a podman version using container files and 'podman' on the command line then there would soon be a plea on the mailing list "Is there a docker version?") As for cost: the command line version of Docker is still free and is fine for running a single instance; and some users may well be companies who choose to pay for Docker so they can obtain support - it's not our place to make that choice for them.
* Nit: Hard-coded references to "linux-64" could use a variable, instead.
The container base OS is linux-64 so it just got hard-coded. If an Alpine version is created then it might make sense to move it to a variable then. Regards, — Bruce Horrocks Hampshire, UK
On 11/26/2025 5:03 PM, Bruce Horrocks wrote:
The container base OS is linux-64 so it just got hard-coded. If an Alpine version is created then it might make sense to move it to a variable then.
one could use 'native' as that is what a luametatex build compiles to we only have these 'names' because one can have parallel installations in the end the bin looks at trees relative to where the bin is Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
I'm not sure what the issue is here.
It's a pet peeve of mine: using a specific term instead of a general term when writing software and configuration files. Instead of a "Docker" image you can make a container image that works with both Docker and podman. Instead of a "Dockerfile" you can call it a "Containerfile" and it'll work with both podman and Docker and whatever other containerization platform comes out in the future. For documentation you can write, "works with Docker and podman" to help the searchers. Speaking of images, another issue with the wiki's example is that there isn't an obvious way to import external images from outside the container environment (i.e., no external directory paths are mapped). Anyway, I recommend looking at the Containerfile I put together, as it adds a number of features to running containerized ConTeXt. Feel free to pilfer or not. Cheers!
On 1 Dec 2025, at 06:24, Thangalin
wrote: I'm not sure what the issue is here.
It's a pet peeve of mine: using a specific term instead of a general term when writing software and configuration files.
Ah, I see. Well, Docker did get there first and for a while there was no other terminology. However a Google has showed me that there does seem to be a general effort to moved to more neutral wording so I'm happy to change the page.
Instead of a "Docker" image you can make a container image that works with both Docker and podman. Instead of a "Dockerfile" you can call it a "Containerfile" and it'll work with both podman and Docker and whatever other containerization platform comes out in the future. For documentation you can write, "works with Docker and podman" to help the searchers.
This would work.
Speaking of images, another issue with the wiki's example is that there isn't an obvious way to import external images from outside the container environment (i.e., no external directory paths are mapped). Anyway, I recommend looking at the Containerfile I put together, as it adds a number of features to running containerized ConTeXt. Feel free to pilfer or not.
Is that the Keenwrite one? https://repo.autonoma.ca/?action=blob&repo=keenwrite.git&hash=e23a2a0f03894070ff01472d36dc133285c39120&name=Containerfile It contains a copyright statement so I wouldn't want to take too much. I think it will be easiest to position the Wiki page as a simple container that provides the minimum needed for people to get going and link to the above containerfile for advanced users. Regards, — Bruce Horrocks Hampshire, UK
Hello ConTeXt community,
Following Bruce Horrocks’s recent message about containers and ConTeXt, I wanted to share a small observation and ask for guidance.
I am a complete beginner regarding Docker and container-based workflows, but I wanted to experiment a bit on my macOS system (MacBook Pro with Apple Silicon). With the help of AI tools I managed to get a ConTeXt LMTX container running successfully.
I am not entirely sure how the ConTeXt distributions end up inside the various container images maintained by the community, but I encountered a reproducible issue that might be relevant — or at least worth mentioning.
Environment
I am not using Docker Desktop.
Instead I run Docker via Colima, installed through Homebrew:
* macOS (Apple Silicon, M1)
* colima 0.6.x
* docker 27.x (client)
* container image from:
registry.gitlab.com/islandoftex/images/context:lmtx
* ConTeXt inside the container reports:
system > ConTeXt ver: 2025.11.24 17:55 LMTX fmt: 2025.11.30 int: english/english
For basic test documents everything works perfectly.
However, when I try to compile some of my older teaching materials that use a combination of:
* TikZ (included through my own module t-math.mkiv),
* itemize structures,
* margin texts,
* buffers reused through \startbuffer / \getbuffer / \dorecurse,
the following happens:
Observed behaviour
* ConTeXt runs without any visible TeX error.
* The .log file contains no errors or warnings beyond normal module loading.
* A PDF is generated — but instead of typeset content, some pages show a large, plain “ERROR” message.
* The error does not occur in my older standalone installation of ConTeXt LMTX on macOS:
the same sources compile correctly outside the container.
After some investigation, isolating parts of the code, and temporarily removing modules, I found:
Cause located experimentally
If I comment out the line in my module that loads TikZ:
\usemodule[tikz]
then the document compiles without the “ERROR” output.
So it appears that:
➡ The issue is triggered by the interaction between TikZ (m-tikz.mkxl) and ConTeXt LMTX inside the container.
To be clear:
I’m not explicitly using TikZ drawings in the affected document — the module simply loads TikZ because I use it in other teaching materials.
What I would like to ask
1. Is this expected behaviour in the current LMTX version?
(i.e. TikZ support being partial or not intended to be used during this phase of development?)
2. Could there be differences between the container build and standalone builds that affect TikZ integration?
3. Is there a recommended way to include TikZ conditionally, so that documents which do not use actual TikZ graphics avoid triggering internal errors?
4. If useful, I can prepare a minimal reproducible example (buffer + itemize + margin text) that triggers the issue when TikZ is loaded.
Additional diagnostic detail
* The issue is not related to Docker/Colima caching, mounts, or filesystem access.
* Buffers, itemize, and my macros all work as expected when TikZ is not loaded.
* The error page appears to be generated by some fallback mechanism in the TikZ module (not by TeX error handling), since the log file remains clean.
________________________________
If this is already known behaviour or a limitation, I would gladly adjust my workflow.
If not, I’m happy to help provide reproducible test cases.
Many thanks to everyone maintaining ConTeXt and the container images!
Best regards,
Jaroslav Hajtmar
Here is the email I am referring to:
4. 12. 2025 v 1:08, Bruce Horrocks
Am 05.12.25 um 16:25 schrieb Hajtmar Jaroslav:
I am a complete beginner regarding Docker and container-based workflows, but I wanted to experiment a bit on my macOS system (MacBook Pro with Apple Silicon). With the help of AI tools I managed to get a ConTeXt LMTX container running successfully.
Maybe better ask real people. And read documentation. The TikZ module is not included in the LMTX distribution, you must install it explicitely: mtxrun --script install-modules --install tikz I’m not sure that this works in a container, see my question that started this thread. One of the texlive containers is probably the best starting point, even if huge. Hraban
On 12/5/2025 4:25 PM, Hajtmar Jaroslav wrote:
To be clear:
I’m not explicitly /using/ TikZ drawings in the affected document — the module simply loads TikZ because I use it in other teaching materials.
then don't load tikz ... it slows down a run (which likely is already slowed down due to the container)
Is this expected behaviour in the current LMTX version?
see Hrabans answer
(i.e. TikZ support being partial or not intended to be used during this phase of development?)
optional (context is more a metapost thing)
Is there a recommended way to include TikZ conditionally, so that documents which do not use actual TikZ graphics avoid triggering internal errors?
maybe some mode
The error page appears to be generated by some fallback mechanism in the TikZ module (not by TeX error handling), since the log file remains clean.
you get the error page for any job that fails Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
It contains a copyright statement so I wouldn't want to take too much. I think it will be easiest to position the Wiki page as a simple container that provides the minimum needed for people to get going and link to the above containerfile for advanced users.
You have my express permission to use as much of that file for whatever purpose you see fit. I've updated the header comment to include a note about public domain. https://repo.autonoma.ca/?action=blob&repo=keenwrite.git&hash=f812e4d2bce30a4cbd73b985d9b12d31cbfec9b5&name=Containerfile
participants (6)
-
Bruce Horrocks -
Hajtmar Jaroslav -
Hans Hagen -
Henning Hraban Ramm -
Max Chernoff -
Thangalin