Closed sebasguts closed 9 years ago
Or, even better, create an external software image layer and put it between the gap-package and the gap-docker image.
This will make the Docker image very large, so a neat solution might be to have a very lean image which just has a basic GAP install, then another image derived from the first one with all the packages. Or alternatively, many derived docker images with different packages.
Problem with an image for each package would be, as far as I understand it, that I cannot use several packages at the same time. As I got it, there is no possibility to actually merge images into one container. So I think all packages, and their additional software, have to be in one image.
Yes, so you don't necessarily want one image with all the packages or one image for each package, but a compromise. Images with sets of packages likely to be used together.
If you are using Dockerfile
s you can "merge" images together with the FROM
keyword, see here for documentation on that:
Okay, but this is not really a merge of two independent images, it's just building the next image on top of another one, as it is already done. I think combinations of packages would than be preferrable. But maybe one big image containing all packages would still be of use.
Perhaps we have to follow a clean approach and have three images as @sebasguts suggested:
1) prerequisites (perhaps named gap-prerequisites
)
2) GAP core system (now gap-container
)
3) GAP and all packages (now gap-docker
)
where each next uses FROM
to refer to the previous one.
One could swap (1) and (2) places, but then we may need to rebuild gap-prerequisites
more often...
I think both orderings would have pro's and con's. Maybe it would be the best to swap places (1) and (2), and build another image gap-docker-alone
on top of gap-container
, only containing gap and packages working without external software. In that way, one would have a lightweight image only containing gap and another one with everything inside, which would then be considerably larger.
If we would not introduce cyclic dependencies, then (1) and (2) would be fully swappable. I'd be happy with any order to start with, as if need be, we would need only to update FROM
to change the order in this pipeline. So let's start with (2) and then (1), why not?
I would envisage that the end user would be mostly interested in (3), and package developer for testing purposes in (1) combined with (2) in any order.
Agreed, I think this is a good option.
Ok, so then I plan to create a repository as soon as we will agree about the name. What about gap-docker-base
? The word docker
in the name will indicate that this is Docker-related, so it will not mislead anyone into assuming that this is the core GAP system, and base
seems to fit equally well both cases of building base
after or before gap-docker
.
I think gap-docker-base is a good name for the repository. What should be in there? Ubuntu-packages that are needed for certain GAP-packages and external software like polymake, 4ti2, etc?
Done: please see the repository at https://github.com/gap-system/gap-docker-base. Yes, to start with, we would like to have there
gap-docker
Dockerfile)I will do this and then upload the dockerfile.
Closing this - task done in https://github.com/gap-system/gap-docker-base
Would it be a good idea to create an image called gap_base or something containing the Ubuntu-packages needed for GAP and software like polymake, 4ti2, and Singular, maybe also M2, which are requested by some GAP packages. Building an GAP-image on top of such an image would make it easier to update the GAP image. The gap_base would then only be updated if newer versions are needed.