www-from-model/content/instruments/ff94c3f9-ce37-43f0-b87c-5ee0f776d845/_index.md
Stephan Heunis 91720317ca
All checks were successful
Deploy on webserver / Build site and deploy on success (push) Successful in 1m12s
Introduce term page template generalizations
Along the same lines as 478015 which introduced a generalization for the taxonomy list page,
this commit generalizes the term page template, so that we can remove all duplicates for
taxonomy-specific layout templates.

Several new partials are introduced that are now used in a term page heading and info section,
specifically for the date, identifiers, links, licenses, and related terms such as persons or
topics. These same partials are also worked into the existing 'taxonomy-list-vertical-item'
partial to remove further redundant code. As part of these changes, new icons were added. Also
content has to be updated to change 'date_created' to 'date' in order to streamline its handling
in the single generalized template. The associated jinja templates were also updated with this
change.

The term page layout can be customized in the same taxonomy's '_index.md' page front matter as
is done for the taxonomy list page customization. Newly introduced options are all sub-properties
of the new 'term' property under 'params':

- 'person_display': When a list of persons are rendered for a given term, what should those
  people be called? This is a string value that defaults to 'Contributors'.
- 'depiction_type': The type of depiction that should be rendered for the given term page (and
  in 'taxonomy-list-vertical-item'), if such a file exists in the term bundle. This expects a
  string that will be matched against image files in the term bundle, and will default to 'depiction'.
  This option is necessary because the depiction registration workflow saves depiction files with
  names representing their types, e.g. 'portrait', 'logo', etc.
- 'show_relations': In which format should term relations be displayed at the bottom of the term page,
  if at all. The default is to display no relations (explicitly: 'none'). Other options include
  'expandable', which will show list of expandable taxonomy groups, each group containing all terms of
  that taxonomy that relate to the current term; and 'congo', which will render the Congo-theme default
  list of related terms.

Here are two example configurations for the term options:

'content/persons/_index.md':
---
title: Persons
params:
  term:
    depiction_type: portrait # portrait | logo | depiction (default)
    show_relations: expandable # expandable | congo | none (default)
---

'content/publications/_index.md':
---
title: Publications
params:
  term:
    person_display: Authors # defaults to 'Contributors'
---

Finally, new config is added to several taxonomy index pages to perform these customizations for terms:
- persons: should render the 'portrait' depiction type and show expandable relations
- publications: display persons as 'Authors'
- instruments: should render the 'logo' depiction type
2026-05-31 23:56:10 +02:00

65 lines
2.2 KiB
Markdown

---
title: Lab-in-a-box deployments
params:
graphRootNodePID: xyzrins:instruments/ff94c3f9-ce37-43f0-b87c-5ee0f776d845
pid: xyzrins:instruments/ff94c3f9-ce37-43f0-b87c-5ee0f776d845
doi: null
date: null
source_code_url: null
documentation_url: null
title: Lab-in-a-box deployments
description: 'This is a collection of deployment workflows for
self-hosted software services, implemented with [pyinfra](https://pyinfra.com).
Most importantly, this collection includes the (meta)data tools of the developed
by the [ORINOCO](https://www.psychoinformatics.de/projects/orinoco/) project, but
the list of supported services also include a number of general purpose solutions,
such as [Hedgedoc](https://hedgedoc.org) or [Gatus](https://gatus.io/).
This effort does not aim to serve every use case and deployment scenario. Instead,
it makes a few central assumptions:
- Users have access to an account on a target machine that allows for root-access
via `sudo`.
- The base OS on a target machine is Debian (12+), or a sufficiently close derivative.
There is no hard dependency, but nothing else has seen significant use (yet).
- Users have means to configure the DNS for a domain they want to use for exposing
deployed services.
- [Caddy](https://caddyserver.com) is used as a web-server/reverse-proxy.
- [Podman](https://podman.io) is used as a container solution.
## Conventions
All provided deployments follow a common set of conventions:
- One service, one user: Each deployment creates/uses a service-dedicated user account.
All code runs in user-space.
- Containerized environments: Code is generally deployed in virtual environments
-- typically user-space podman containers, but [uv](https://docs.astral.sh/uv)-managed
virtual environments for (small) Python packages.
- Systemd: Services are managed via user-space [systemd](https://systemd.io) service
units.
- Subdomains: Services are assumed to be deployed using dedicated subdomains (`service.example.org`,
rather than `example.org/service`).'
kind: Software
author: []
topic: []
license:
- pid: spdxlic:MIT
label: MIT License
url: https://spdx.org/licenses/MIT
---