Open cabo opened 4 years ago
That's an interesting question. The way that I've resolved that in the past is to fork the docker image and use my own. Which is a little clumsy, of course.
There is an intermediate step where the docker image is a little more conducive to being built on top of. The switching to a user account in there makes it hard to do anything that requires root access.
For something trivial, adding prerequisites to the Makefile and installing on demand also works, but that isn't really the best option either.
I am reminded of the folly of frameworks, as opposed to libraries, and find myself hating the part where I end up maintaining a framework (ಥ﹏ಥ)
I now have a process that I'm trialing, at least for those on GitHub Actions. If, rather than the @v1 action, you use the @v1m action, you get access to a larger image, for which the bar for including additional tools is much lower. The image has a -math label, but I'm thinking that I will rename it to -mega instead. Most people don't need this sort of integration, so the @v1 can stay fast and lean. Opting for @v1m will mean that your builds are far less efficient, but it should be possible to include tools.
There is also the option of just adding an install step to builds, as described in the documentation.
FYI, recently I made https://github.com/larseggert/i-d-toolchain, which tries to install "all the tools". A fresh image is built every six hours with the latest versions.
Wondering if I should scrap my image and instead use your (possibly extended) meta image...
Upcoming work will let you specify prerequisites in a requirements.txt/Gemfile/package.json (or all of these) and have them automatically installed (and cached in CI builds). This should help relieve pressure on the docker images.
Upcoming work will let you specify prerequisites in a requirements.txt/Gemfile/package.json (or all of these) and have them automatically installed (and cached in CI builds). This should help relieve pressure on the docker images.
Just FYI, re: adding extra packages via Gemfile, I'm having troubles with the Ruby environment installed in the Docker images (both v1 and v1m). See #344
https://travis-ci.org/core-wg/senml-versions fails, because the docker image does not contain
tex2mail
.Now the usage of tex2mail in that document is a bit of a joke, but in other documents there are already uses of other tools external to kramdown-rfc such as goat and svg-check, and the list that kramdown-rfc "can" use will grow further.
I'm wondering what might be a good process to handle that growth. Does all this authoring stuff even belong in the docker image? I'd argue it does.