-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docker updates #8
base: develop
Are you sure you want to change the base?
Docker updates #8
Conversation
- 2 stage build process - changes needed after the PG-2.17 update and the changes to how codemirror is included. - update build instructions and other things in README.md
I have not tried out the |
I haven't had a chance to test this yet, but I question if a two stage build is that beneficial for the standalone renderer. On a related note, I have noticed that there are some things that are missing from the docker build. For example, the |
Building a renderer image when only the renderer or PG code needs to be updated is significantly faster with a 2 stage build, so I do find it convenient, and have been doing it for a while.
That makes sense. AFAIK the package selection mostly dates back to the early days of the renderer (the work by Rederly and whoever was helping them back then), and apparently did not take into account problems which depend on such features of PG. It is worth noting that adding LaTeX and the other tools you mentioned will probably greatly increase the size of the image. I doubt that there is any good alternative, as moving the handling of calls to latex, dvisvgm, etc. outside of the renderer container would require creating separate micro-services to handle the "external tool" calls, and the additional services would depend on the large set of dependencies. |
Adding LaTeX will increase the image size quite a bit. Adding the other tools won't do much. LaTeX is the only one of any real significant size. I don't think that there is really a good alternative to adding it to the image. Updating an image when only the pg or renderer code has changed is the pretense for a two stage build. Similar to the pretense for a two stage build for webwork2. Here is the thing about that. Usually, the only time you need to update the code for the underlying git repository is on an upgrade. As developers we do that a lot, and I am guessing that is why you want this two stage build. However, as a developer you really should not be running webwork2 or the renderer in a docker container. That is insanity. If you want to be useful as a developer, you need to stop doing that. |
Intended to make the Docker build work, and to split it into a 2 stage build, so the underlying OS packages and CPAN installs need not be redone for each rebuild of the main image.
Changes were made to use
docker-compose
which makes it easier to have persistent settings for additional mounts, etc. rather than putting everything into thedocker run
command.It also updates the build instructions in
README.md
and points those to use the openwebwork repository and not the drdrew42 repository.Note:
.git
was removed from.dockerignore
as otherwise thenpm install
insidelib/PG/htdocs
is failing.This replaces #4 and is built on top of the current develop branch.