make references to "Models and Docker" much more prominent

[bertsky]

Currently, the section explaining how to install models and run processors with Docker – which requires some form of persisting processor resources – is completely hidden here.

IMO it should be referenced (hyperlinked) in the Setup Guide, right after testing the Docker installation, in a short section Installing models (and yes, that section should exist for the native and individual option as well). Also, in the User Guide, rename Usage of models to Using models and also link back to the (new section on model downloading in the) Setup Guide. Also, consistently all docker run examples should carry the models volume besides the data volume throughout.

[bertsky]

ping @lena-hinrichsen

[bertsky]

BTW, Models and Docker currently does not cover the config volume needed for resources.yml (model user database). (It's also missing on the ocrd_all readme...)

[lena-hinrichsen]

These are the tasks I extracted from this issue:

• Make references to the Model page in the Setup Guide (for each installation option)
  => I hope this is solved with make models page in setup guide more prominent and rearrange  #348

• rename the Models Section in the setup Guide
  => rename models section in user Guide #349

• Make references in the User Guide
  => Instead of linking back to the Installation Guide, I tend to link to the Models page instead. What do you think?

• "all docker run examples should carry the models volume besides the data volume throughout"
  => Does this affect each command in https://ocr-d.de/en/user_guide or can we at least skip the Preparing a workspace section?

• make changes in https://ocr-d.de/en/models#models-and-docker according to the last comment make references to "Models and Docker" much more prominent #318 (comment)
  => @kba can you add this or shall I create an issue and you tell me more details?

• make changes in ocrd_all readme according to the last comment make references to "Models and Docker" much more prominent #318 (comment)

[kba]

=> Does this affect each command in https://ocr-d.de/en/user_guide or can we at least skip the Preparing a workspace section?

No, the ocrd CLI itself does not need any resources.

[kba]

• make changes in https://ocr-d.de/en/models#models-and-docker according to the last comment make references to "Models and Docker" much more prominent #318 (comment)
  => @kba can you add this or shall I create an issue and tell me more details?

BTW, Models and Docker currently does not cover the config volume needed for resources.yml (model user database). (It's also missing on the ocrd_all readme...)

The issue is that if you download a resource, it will be added (and the file created if non-existant) to $HOME/.config/ocrd/resources.yml. To make that list persistent, there should be a host directory ./config (or similar) and it should be mounted like this:

  --volume $PWD/config:/.config/ocrd \

[bertsky]

To make that list persistent, there should be a host directory ./config (or similar) and it should be mounted like this:

@kba perhaps my thinking was not right though. I remember seeing problems by not having a /.config/ocrd/resources.yml writable. But that could be remedied by providing a sensible default for XDG_CONFIG_HOME. I don't think we actually need a persistent config itself. (And with dynamic resource discovery, perhaps we need no user config at all now?)

[lena-hinrichsen]

@kba @bertsky Do we still need --volume $PWD/config:/.config/ocrd \ as a parameter for docker calls when downloading models? (that means especially for https://ocr-d.de/en/models )

[bertsky]

@kba @bertsky Do we still need --volume $PWD/config:/.config/ocrd \ as a parameter for docker calls when downloading models? (that means especially for https://ocr-d.de/en/models

@lena-hinrichsen I'm afraid yes, for the moment we still do. That's because

• we still do (generate and) parse a ocrd/resources.yml user DB
• we still do not set XDG_CONFIG_HOME in ocrd_all (which we should, ideally to /usr/local/share/ocrd-resources, consistent with XDG_DATA_HOME, so in the future, a single volume would be enough)