Konstantin Baierer

> In Bashlib, we could add a new subcommand `ocrd bashlib add-agent -m mets.xml [other-params]`, and wrap that in some exported function `ocrd__add_agent` in lib.bash to be used by processors...

> > Exactly, but I would prefer an `ocrd workspace add-agent` subcommand for consistency. > > To be consistent with what exactly? I mean consistent with e.g. `ocrd workspace set-id`,...

> > I mean consistent with e.g. `ocrd workspace set-id`, i.e. have all the METS metadata functionality in `ocrd workspace`. > > ok, got it. But then we should also...

> What does the resmgr log say? Nothing interesting, it only logs what it **is** downloading, not what it's supposed to be downloading or how it decided which processors should...

I've opened a separate issue for the `ocrd-all-tool.json` aspect in https://github.com/OCR-D/core/issues/1059

Implementing [this](https://github.com/OCR-D/core/pull/974) in bashlib processors will be very difficult. Honestly, at this point, I'm wondering whether we want to / can continue to support bashlib fully or whether it wouldn't...

> The latter must always be possible, otherwise developers will have to reimplement our conventions for Java, C++, Go, whathaveyou. I'm very fond of bashlib, don't get me wrong. But...

> Also, does anybody know what's wrong with the Scrutinizer setup? AFAICS it hangs because `apt` is not called with `-y`, so it asks questions and times out waiting for...

> Perhaps we should make the cardinalities a property in `ocrd-tool.json` and enforce that in the superclass? Since the cardinality is defined as a constant, I see no reason not...

> Unfortunately, in the current state, I reintroduced the problem that if a processor has mandatory parameters without defaults, you cannot instantiate it _without_ those. So not only does `--help`...