| 05:36 | <MikeSmith> | Domenic: nevermind, I see now that the `docker run` invocation in build.sh is actually using --mount |
| 11:19 | <andreubotella> | annevk: the list shorthand doesn't allow a spread syntax, right? |
| 11:38 | <andreubotella> | actually, never mind |
| 12:58 | <Domenic> | MikeSmith: right, also note that build.sh doesn't actually use the Wattsi docker image via `docker run`; it pulls in the binary into its own separate docker image. |
| 12:58 | <Domenic> | I think this is where docker-compose is supposed to come in... e.g. if I wanted to pull in the html checker from one docker image, pdfsizeopt from another, and wattsi from a third... |
| 13:00 | <jgraham> | docker-compose is for running mutliple images at the same time. If you just want to build a docker image with parts from several parents, I think multi-stage builds might be the right thing |
| 13:07 | <Domenic> | The problem I ran into is that I don't know _where_ in the docker image the binary is. (I could probably track it down by introspecting the container, but it's not obvious which part of the container's $PATH it's in.) |
| 13:07 | <Domenic> | I'd like to be able to do multiple `docker run`s on the same mounted filesystem |
| 13:08 | <Domenic> | Since `docker run` just uses the entrypoint, thus letting the actual location of the binary stay as an implementation detail of the container I'm `docker run`ing. |
| 14:40 | <annevk> | Domenic: why are 26.4.1.2 and 26.4.1.3 not reusable too? |
| 14:40 | <annevk> | Domenic: I agree that if we cannot reuse the [[Properties]] setup it's a bit meaningless |
| 14:41 | <Domenic> | annevk: 2 is reusable I guess but it's a given; I wouldn't call it reuse as much as a fundamental building block. 3 is not reusable because it is creating a generic property bag for unbounded properties. |
| 14:41 | <annevk> | Domenic: well but we'd only copy a select set of properties instead |
| 14:41 | <Domenic> | We'd need some separate store for the non-enumerable properties |
| 14:41 | <Domenic> | Otherwise it'd install them as enumerable |
| 14:41 | <annevk> | Domenic: ah I see, hmm |
| 14:43 | <annevk> | Domenic: I guess the only thing left at that point would be to use deep as inspiration so we don't have per-property logic for errors |
| 14:43 | <Domenic> | Yeah |
| 14:43 | <annevk> | Domenic: (I wouldn't mind not stringifying message) |
| 14:43 | <Domenic> | That's basically what I was saying if we want to add implementation/test churn by revisiting message |
| 14:43 | <Domenic> | I think it's the better model but I'm not sure it's worth it |
| 14:44 | <annevk> | k, I guess I'll wait for others to chime in |