Mike Gerber

> If you hope to achieve all-in-one (fat) builds without sub-venvs, then let me reiterate that this is fruitless: there will always be _some_ conflicts around the corner in this...

Q&D ocrd AppImage to be built with `pkg2appimage`: ~~~ # Based on https://github.com/AppImage/pkg2appimage/blob/9249a99e653272416c8ee8f42cecdde12573ba3e/recipes/ProcDump.yml app: ocrd ingredients: dist: bionic sources: - deb http://us.archive.ubuntu.com/ubuntu/ bionic bionic-updates bionic-security main universe - deb http://us.archive.ubuntu.com/ubuntu/...

My opinion(!) on this: If OCR-D has everything either 1. pip installable (for Python source) 2. apt installable on Ubuntu LTS (everything else) a. OCR-D things not covered by pip...

(My fat container approach https://travis-ci.org/github/mikegerber/my_ocrd_workflow has the same Gordian knot, I just include fewer processors.)

And you can then still stick an AppImage into a Ubuntu package. It's a bit perverse but easy to do. (Needs a bit more work if you have e.g. a...

proof-of-concept AppImage for ocrd core: https://github.com/OCR-D/ocrd_all/issues/130#issuecomment-663075594

From what I can see (https://github.com/OCR-D/ocrd_all/issues/130#issuecomment-663075594) the one big problem is the handling of the working directory. Other than that it seems relatively easy to do.

I think OCR-D has to decide if you want a "have it all" environment. Then either separate venvs per processor or some kind of Docker setup could be the solution....

``` docker run --rm -t --user `id -u`:`id -g` --mount type=bind,src="$(pwd)",target=/data ocrd_example_processor ```

> The only thing that troubles me with delegating to thin module Docker containers is that we more or less surrender version control. It's really difficult to do that with...