Dockerizing a Programming Language

charcircuit wrote: post #2

Doesn't docker seem overkill compared to just a package for a package manager or statically compiling Z3 into your binary?

When you're running multiple projects expecting the same globally installed library or shell command (but a different version), building/running in docker is a breeze: each container can have its own set of dependency versions.

Re: Dockerizing a Programming Language

#5

Post by secondcoming » Mon, Jan 10, 2022, 9:12 AM UTC

Docker all the things!

Re: Dockerizing a Programming Language

#6

Post by chriswarbo » Mon, Jan 10, 2022, 10:08 AM UTC

I get the arguments for using containers, but why use Docker? Especially if you're already using Make? Building a container image is pretty simple in Make (or bash, or anything else); you just copy a "config.json" into the output directory, tar it up, and write its sha256 to a "manifest.json" file.

Update: If you want to include other "layers", e.g. if the Z3 project provides its own image, then just put their SHA256 in the manifest.json too.

Re: Dockerizing a Programming Language

#7

Post by chriswarbo » Mon, Jan 10, 2022, 10:14 AM UTC

laurensr wrote: post #4

charcircuit wrote: post #2

Doesn't docker seem overkill compared to just a package for a package manager or statically compiling Z3 into your binary?

When you're running multiple projects expecting the same globally installed library or shell command (but a different version), building/running in docker is a breeze: each container can have its own set of dependency versions.

> globally installed library or shell command

There's your problem! Different versions of anything can coexist if they're installed to separate locations; e.g. Nix does this by using the `--prefix` option of each project's './configure' script.

Re: Dockerizing a Programming Language

#8

Post by nkuttler » Mon, Jan 10, 2022, 10:31 AM UTC

chriswarbo wrote: post #7

laurensr wrote: post #4

Earlier quoted context omitted.

When you're running multiple projects expecting the same globally installed library or shell command (but a different version), building/running in docker is a breeze: each container can have its own set of dependency versions.

> globally installed library or shell command There's your problem! Different versions of anything can coexist if they're installed to separate locations; e.g. Nix does this by using the `--prefix` option of each project's './configure' script.

Docker is just another solution to the problem.

Re: Dockerizing a Programming Language

#9

Post by chriswarbo » Mon, Jan 10, 2022, 11:33 AM UTC

nkuttler wrote: post #8

chriswarbo wrote: post #7

Earlier quoted context omitted.

> globally installed library or shell command There's your problem! Different versions of anything can coexist if they're installed to separate locations; e.g. Nix does this by using the `--prefix` option of each project's './configure' script.

Docker is just another solution to the problem.

It's a rather convoluted one though: rather than telling libraries to install in different places, they're installed "globally" within a chroot, which then gets tarred-up, which then gets untarred, then bind-mounted, then chrooted-into again.

Re: Dockerizing a Programming Language

#10

Post by faeyanpiraat » Mon, Jan 10, 2022, 11:38 AM UTC

nkuttler wrote: post #8

chriswarbo wrote: post #7

Earlier quoted context omitted.

> globally installed library or shell command There's your problem! Different versions of anything can coexist if they're installed to separate locations; e.g. Nix does this by using the `--prefix` option of each project's './configure' script.

Docker is just another solution to the problem.

A cross platform solution, which is nice.