Bumbed version to 7.7.1. Also

[JanWielemaker]

• Move constants to docker environment vars
• Disables libdir versions, so we get /swipl/lib/swipl without versions
• Install space from the addon registry. space is not part of the tarball.

[ninjarobot]

Would this make sense as an additional image tag, i.e. swipl:7.1.1-space? It could be based off the 7.1.1 release, but adds space. We could have another Dockerfile that is little more than FROM swipl and then RUN for the space build. Or should this always be part of the full image?

[JanWielemaker]

I'm against a -space. We have SWI-Prolog's real core, its library that is bundled with the core, its packages that are bundled in the tar archive and can be compiled separately and community packages. None of the boundaries are very hard. Space went from the 2nd to the 3rd class because it is fairly hard to install in arbitrary environments, causing lots of porting issues while it is not vital. I got feedback from two people telling me that including space was a good idea (they looked at the Dockerfile and saw it included), so I first wanted to make that work.

Supporting space in the docker image doesn't change much of its size, while in the controlled Debian stretch environment we can get it installed fairly easily. The same goes for a couple of other add-ons, I think some 3 or 4. They add seconds to the build time and altogether probably a couple of Mb to the image size. Including them will make the image read-to-use for a significantly larger class of server tasks without having to setup the build essentials and add them to your own image. I think there are two options:

• Just include them
• Have a swipl:xl version.

Considering simplicity for the users I'm in favour of (1). Note that we are only interested in mixed C/Prolog add-ons. Pure Prolog ones are installed very quickly.

In particular when we have a layered Dockerfile the thing should be quite manageable. I'll spend some time adding this stuff today. Getting it to build is hard, while reorganizing is quick.

[ninjarobot]

I was avoiding these, as each directive results in a new image layer, albeit a small one. If we switch to a multi-stage build, that's largely irrelevant.

[JanWielemaker]

So, let us create layers. Do you do this or do you leave it to me?

[ninjarobot]

@JanWielemaker I had just a few comments, as I expect I'll have similar questions from the official image curators.

[JanWielemaker]

Its so simple that I did the multi-stage build. The image is now 139 vs 136 Mb, but we have the space package (2.3Mb and the ca-certificates (small)). So, it seems we are ok. It is surely a lot simpler like this!

[JanWielemaker]

Dave, I think I've reached a stage in which I like to have this. Including 5 add-ons that are needed in server setups people around me use a lot and often have trouble building. They makes the image grow from 136Mb to 148Mb. Possibly this can be reduced a bit further by deleting some test, demo and documentation files.

If you don't like this, I propose you split it into the plain swipl and a swipl:xl or something similar. I've reorganised the apt dependencies a little to hint what belongs to what so you can easily split them.

[ninjarobot]

Jan - thank you, this looks great, the resulting image doesn't have any of the layers from the build image definition.

One strange thing I see, the ENV values which are in the build image seemed to make their way into the final image, so if I run set on a container from the final image, I see environment variables like SPACE_SHA1=cd6fefa63317a7a6effb61a1c5aee634ebe2ca05.

@tianon or @yosifkit - should the ENV from a builder image make their way into the final image or is this a bug? Also, any other concerns with this Dockerfile? Is everything acceptable with the pulls from a few other GitHub repos?

[ninjarobot]

REF: moby/moby#35174

[tianon]

Unfortunately, the official-images infrastructure cannot support multi-stage builds; see docker-library/official-images#3383.