Skip to content
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

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

taniwallach
Copy link
Member

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 the docker 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 the npm install inside lib/PG/htdocs is failing.

  • 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

This replaces #4 and is built on top of the current develop branch.

  - 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
@taniwallach
Copy link
Member Author

I have not tried out the Dockerfile_with_OPL which was apparently added to include the OPL inside the Docker image for some use cases. In that file, it seems that it may be necessary to replace master with main in several places. It could be that GitHub is automatically handling some redirect so that the "old" approach still works.

@drgrice1
Copy link
Sponsor Member

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 LaTeXImage module uses latex, obviously. So clearly the texlive package is needed. Some other texlive packages are probably needed too. The dvisvgm and pdf2svg packages are needed as well.

@taniwallach
Copy link
Member Author

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.

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.

On a related note, I have noticed that there are some things that are missing from the docker build. For example, the LaTeXImage module uses latex, obviously. So clearly the texlive package is needed. Some other texlive packages are probably needed too. The dvisvgm and pdf2svg packages are needed as well.

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.

@drgrice1
Copy link
Sponsor Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants