check for system dependencies in a user-friendly way

[bertsky]

Might be relevant to the spec itself: We now have deps-ubuntu as a means to encapsulate system dependencies of modules, but no way to check that these are met – not even for Ubuntu itself.

For Ubuntu itself, it would be easy to introduce an extra target check-deps-ubuntu which fails (with a good error message) when one of the packages (or even PPAs) is missing. Of course, that would also have to be implemented in all the modules which already have/need deps-ubuntu.

But I don't know of any OS-independent checks besides things like pkg-config. And then the (package) names of those dependencies might be different again, hence the need to lay hands on the individual modules' dependencies – which we wanted to encapsulate with deps-ubuntu (alone).

So for the weaker goal (Ubuntu only), I don't think it is worth the effort (as one could instead always install just in case). And for the stronger goal (OS-independent), I'm afraid we have to postpone that in the same way we postponed OCR-D/spec#131.

[kba]

It's a good idea and we should implement it after the worksshop.

[bertsky]

In general we should think of this as some kind of host adaptor for local installation: we could have a make target (e.g. make host) or script (e.g. configure) that does various extra steps which allow satisfying system dependencies:

1. detecting the OS and distribution (e.g. for macOS: which package manager)
2. installing OS/distro-specific general requirements
3. translating the system dependencies of the (selected) modules into a list of commands for both checking (without priviledges) and installing (with priviledges) them on the detected OS/distro

Using autoconf for this would already preclude macOS and Windows, right? Is there anything else we could use?

[bertsky]

But I don't know of any OS-independent checks besides things like pkg-config.

Plus we have many more dependencies besides just libraries.

Thus, along the host adaptor idea, maybe all mapping work should be focussed on "simulating" on the respective system what Ubuntu provides. Otherwise we will inevitably shift the burden to the module providers. We could even go so far to install custom apt dummies under our venv PATH, so that deps-ubuntu etc will work ever after.

[bertsky]

We could even go so far to install custom apt dummies under our venv PATH, so that deps-ubuntu etc will work ever after.

This would need to sneak past any existing apt if the host is not exactly Ubuntu 18.04 (e.g. 20.04), and install a venv already during deps-ubuntu.

A weaker, intermediate goal: allow running make -n deps-ubuntu to just see what dependencies there are. The problem is: make -n would not run the commands for the git submodules, so the recursive part of deps-ubuntu will fail (because there are no makefiles under the module directories in a fresh clone). We have already seen the same unfortunate interdependency with the sudo issue (needing priviledges for apt, but not for git submodule).

Perhaps deps-ubuntu should be rewritten such that it only dives into submodules if they already exist. Then one could use it in multiple stages:

• on non-Ubuntu: make -n deps-ubuntu; ... make modules; make -n deps-ubuntu; ...
• on Ubuntu: sudo make deps-ubuntu; make modules; sudo make deps-ubuntu