Alpine texlive

[svenevs]

Not quite ready for merge yet, see review.

Fixes #1 .

Warning: currently this produces a 2.25 GB image. ncdu reveals that this is mostly fonts (specifically from texmf-dist-most), so maybe we can choose to be more selective with that. But there seem to be a lot of hidden dependencies with latex and fonts that are actually required.

I can retry with less stuff installed, but I need guidance on how to actually test the full latex side of pandoc.

[svenevs]

I've been thinking about how to structure this. I think this would be reasonable if we created pandoc user on docker hub

1. pandoc/alpine repository (is currently tarleb/alpine-pandoc).

   • Add master tag. Or edge? I'm confused by edge vs master in the Makefile.
   • Add 2.5 (stable) tag.
   • Push :latest as 2.5.
   • Maybe moving this into alpine/base was bad or misleading? I like FROM pandoc/alpine:tag better than FROM pandoc/alpine-base:tag for people who just want pandoc. Easy to fix / revert.

2. Add pandoc/alpine-texlive repository which builds on top of (1).

I've been thinking about how to deal with automation here. Some brief reading online seems to indicate that builds on docker hub can run for a maximum of two hours. Locally (with a parallel build), the base image that actually builds pandoc took ~35 minutes. So on their (serial, I believe) builds we will probably not timeout.

Since the code in the docker files are not really going to be changing that much, what we can do is trigger from the web and just setup a cron build job with Travis CI or something. Perhaps triggering a master (edge?) build maybe once a month?

The :latest and official release versions would basically just get built once and stashed, and the :master tag would be a rolling tag. Does this make sense?

[svenevs]

@jgm Is rsvg-convert the tool you were talking about? I found this patch, but it's not mentioned explicitly in the MANUAL so I'm not really sure.

[tarleb]

This is a great start.

I'm not sure about the -j though, please you open a separate PR for that.

[svenevs]

I think we got our wires crossed a little in terms of the naming. Instead of pandoc/core, should that repository be renamed to pandoc/alpine? Then additionally create pandoc/alpine-tex repository?

Maybe we could do both. It seems like good style to provide obvious choices for users, so people don't have to understand the naming scheme first. We could tag the core image as both core and alpine-core, and same for latex and alpine-latex. This would make it easy for users to pick an image, while giving us the freedom to add more operating systems later.

[tarleb]

I accidentally edited your comment instead of writing a proper reply (yes, I need some coffee). See above.

[tarleb]

I'm confused by edge vs master in the Makefile.

Me too, tbh ;) I was under the impression that edge is commonly used for the bleeding edge image, while master is more of a git thing. I think I prefer edge, but I'd also be ok with dev or master.

• Add 2.5 (stable) tag.
• Push :latest as 2.5.

Good idea.

I've been thinking about how to deal with automation here. Some brief reading online seems to indicate that builds on docker hub can run for a maximum of two hours. Locally (with a parallel build), the base image that actually builds pandoc took ~35 minutes. So on their (serial, I believe) builds we will probably not timeout.

Let's try it then 👍

[svenevs]

I'm not sure about the -j though, please you open a separate PR for that.

Results gathered. No -j builds in 25m16.036s and with -j builds in 32m29.685s. How overwhelmingly dissatisfying, good thing you knew about this!

Maybe we could do both. It seems like good style to provide obvious choices for users, so people don't have to understand the naming scheme first. We could tag the core image as both core and alpine-core, and same for latex and alpine-latex. This would make it easy for users to pick an image, while giving us the freedom to add more operating systems later.

I agree with the sentiment, FROM pandoc/core:tag or FROM pandoc/latex:tag is pretty darn clear. I don't think mirroring to pandoc/alpine:tag and pandoc/alpine-latex:tag is really necessary though. We can just clearly define in the readme that the core images are alpine linux. Then if we add newdistro, we will produce pandoc/newdistro and pandoc/newdistro-latex repositories. Basically, it seems like an unnecessary maintenance overhead to mirror pandoc/core as pandoc/alpine.

But I really don't actually care that much. Just trying to reduce workload.

I was under the impression that edge is commonly used for the bleeding edge image, while master is more of a git thing. I think I prefer edge, but I'd also be ok with dev or master.

I know little to nothing of the common practices. :edge being a build of the master is no more or less clear provided we document it. I'll add a docs PR once we establish the core and latex vs alpine stuff. AKA once we've "stamped a final decision" I'll open that PR.

Let's try it then 👍

First attempt on my fork does not bode well. Locally I was able to build pandoc/core image with and without -j in about an hour (with a docker system prune --all --force in between), but the build is still currently running. It's probably going to timeout. Slash I'm going to give Travis CI a try instead. We get 50 minutes to build on a public repository, given that most of the Travis machines have some nice Intel Xeon processors and my local machine (which is not so nice...) takes 25 minutes, that's probably a better approach.

[svenevs]

status update: docker hub build took almost 2 hours. Travis CI is potentially a good fit, but the base alpine image runs dangerously close to the 50 minute time limit. I tried to docker pull and do --cache-from as described here but no layers utilized the cache for any steps so I removed it.

• Example build: https://travis-ci.com/svenevs/dockerfiles/builds/99645029
  • Temporary hosting of base image: https://cloud.docker.com/repository/docker/svenevs/core
  • Temporary hosting of latex image: https://cloud.docker.com/repository/docker/svenevs/latex
    • Timings for the latex image not accurate, somehow even though I deleted tag :2.4 the docker push command magically knew it already existed somewhere. Build Documentation #9 is going on right now with an earlier version.

It's kind of strange that it takes almost double the time to build on travis than it does locally, this desktop is not that powerful. I will do a little more research / am waiting until tomorrow to see what happens with the cron build for next :edge tags. There are other caching options that can be tried, but I suspect that cabal / ghc are the bottleneck here. It takes a long time to download all of the dependencies even just for cabal install cabal-install.

Will open a PR soon 🙂