[rfc] speed up build times

[turbio]

The long build times for polygott seems to be a pretty universal issue. Specifically phase2 (the language installation step) must almost always run and takes by far the longest.

Proposed solutions:

• Build the base image (phase0 + phase1), an image for every language (phase2), then copy the relevant contents out of the the language images into a single unified image.
  • It's probably going to be tricky to define the relevant content and we'll to list that somewhere llike the toml.
• Build the base image (phase0 + phase1) followed by an image for every language (phase2) based on that base image.
  • This betrays a goal of polygott as every language is now isolated. We may want to choose a set of languages we deem important to be included in the base image.

[raxod502]

I know it's probably impossible to change the base image, but I will point out that in my experience using APK on Alpine Linux in Docker, the installation times are way faster. For example, apt-get update && apt-get install -y file takes 7.5s, while apk update && apk add file takes 0.5s. (Not that this is a representative experiment by any means.)

[kochman]

I think solution two is DOA due to isolating languages.

I like the idea of the first solution; I was playing around with figuring out how flexible it'd be. I'm not sure if we could easily always straight-up copy language-specific stuff into a unified image—I think we'd need to figure out how to resolve filename conflicts, for instance, though maybe we could leverage some parts of the .deb packages to figure out exactly what we need to copy out of the image. I think going down this path might end up with us solving the same problems as a distro package manager, but it might be our best bet.

So a potential third solution, just for thought: take advantage of the package manager and create a polygott meta-package that depends on language-specific packages, such as polygott-python3 or polygott-bash. Those individual packages could usually just depend on distro-provided packages. The packaging could be scripted based on the TOML files and handled behind the scenes, and then building the polygott image would boil down to installing that one big polygott package and letting apt figure out the rest. I don't think I'm a big fan of this idea because I haven't worked much with Debian packages, and I don't know if this would actually give us a meaningful speedup over the Docker-based phases.

Ultimately, what polygott is doing is installing dozens of languages and hundreds (thousands?) of their dependencies, which is inherently a lot of work. We can definitely work on making the development experience tighter for individual languages, but if the goal here is to have everything in the same image then I'm not sure how much faster things can realistically be, and I think we might just have to wait it out.

Also @raxod502: so there's almost certainly room for improvement at the package manager level that we could experiment with.

[raxod502]

so there's almost certainly room for improvement at the package manager level that we could experiment with

Yes, but part of the improvement comes from the fact that APK's repositories contain packages that are compiled to be smaller and more lightweight.

if the goal here is to have everything in the same image then I'm not sure how much faster things can realistically be

We are fine with it taking 40 minutes to build the whole image. What we want is to be able to rebuild the image in much less time if we only modify one language. I think this is possible at least in principle.

I think solution two is DOA due to isolating languages

In principle it sounds like a problem, but in practice how many Node apps are going to need to start Swift subprocesses? I think we could just figure out what are the combinations people actually want, and then support those (e.g. each TOML file could have a list of other languages to be compiled into that language's image).