e1f81e5274
* docs(config): Clarify preset ordering priority Refs #1276 * docs(architecture): WIP Narrative how it works Much of this is repetition of the reference docs and some of the changes here should also be applied here. The goal is to repeat here the parts of the reference docs that may hang up a user when reading "Getting Started" without sending them off to get lost in the weeds of the reference docs. Note that this references a `Quick Start` document which is just an empty placeholder and is to be written in a subsequent change. Fixes #1279 * docs(terms): Glossary redundant with architecture Now that the introduction includes an architectural overview, that section introduces new users to necessary concepts and associated terminology and makes the terminology section redundant in that part of the docs. * docs(quick): Add a rote quick start guide This is what I came up with when I tried to write instructions requiring as little understanding as possible. Doing so really did reinforce my impression that this just shouldn't be done, that significant understanding is required for *any* use of ytdl-sub and even offering a quick start may be irresponsible. I'm still on the fence, thoughts? That said, I also think I got some good explanations out of this and a better understanding of what the next bits of the Getting Started should be. This Quick Start is currently redundant with other parts of the Getting Started pages. I suspect that I'll end up repeating and/or reorganizing parts of this Quick Start into the next bits of the Getting Started. To that end I might argue that this change is a WIP and that merging should wait. But I could also argue that this is an incremental improvement and can be merged before that other work. Your call. * docs(start): Various rST/Sphinx markup issues
99 lines
2.6 KiB
ReStructuredText
99 lines
2.6 KiB
ReStructuredText
==================
|
|
Configuration File
|
|
==================
|
|
-----------
|
|
config.yaml
|
|
-----------
|
|
|
|
ytdl-sub is configured using a ``config.yaml`` file.
|
|
|
|
The ``config.yaml`` is made up of two sections:
|
|
|
|
.. code-block:: yaml
|
|
|
|
configuration:
|
|
presets:
|
|
|
|
You can jump to any section and subsection of the config using the navigation
|
|
section to the left.
|
|
|
|
Note for Windows users, paths can be represented with ``C:/forward/slashes/like/linux``.
|
|
If you wish to represent paths like Windows, you will need to ``C:\\double\\bashslash\\paths``
|
|
in order to escape the backslash character.
|
|
|
|
configuration
|
|
~~~~~~~~~~~~~
|
|
The ``configuration`` section contains app-wide configs applied to all presets
|
|
and subscriptions.
|
|
|
|
.. autoclass:: ytdl_sub.config.config_validator.ConfigOptions()
|
|
:members:
|
|
:member-order: bysource
|
|
:exclude-members: subscription_value, persist_logs, experimental
|
|
|
|
persist_logs
|
|
""""""""""""
|
|
Within ``configuration``, define whether logs from subscription downloads
|
|
should be persisted.
|
|
|
|
.. code-block:: yaml
|
|
|
|
configuration:
|
|
persist_logs:
|
|
logs_directory: "/path/to/log/directory"
|
|
|
|
Log files are stored as
|
|
``YYYY-mm-dd-HHMMSS.subscription_name.(success|error).log``.
|
|
|
|
.. autoclass:: ytdl_sub.config.config_validator.PersistLogsValidator()
|
|
:members:
|
|
:member-order: bysource
|
|
|
|
presets
|
|
~~~~~~~
|
|
``presets`` define a `formula` for how to format downloaded media and metadata.
|
|
|
|
This section is work-in-progress!
|
|
|
|
preset
|
|
""""""
|
|
Presets support inheritance by defining a parent preset:
|
|
|
|
.. code-block:: yaml
|
|
|
|
presets:
|
|
custom_preset:
|
|
...
|
|
parent_preset:
|
|
...
|
|
child_preset:
|
|
preset: "parent_preset"
|
|
|
|
In the example above, ``child_preset`` inherits all fields defined in ``parent_preset``.
|
|
It is advantageous to use parent presets where possible to reduce duplicate yaml
|
|
definitions.
|
|
|
|
Presets also support inheritance from multiple presets:
|
|
|
|
.. code-block:: yaml
|
|
|
|
child_preset:
|
|
preset:
|
|
- "custom_preset"
|
|
- "parent_preset"
|
|
|
|
In this example, ``child_preset`` will inherit all fields from ``custom_preset`` and
|
|
``parent_preset`` in that order. The bottom-most preset has the highest priority. More
|
|
specifically, presets are merged using `mergedeep`_ via `a TYPESAFE_ADDITIVE merge`_,
|
|
which means:
|
|
|
|
- if two conflicting keys arent lists or mappings, overwrite the higher priority one
|
|
- otherwise, combine then re-evaluate
|
|
|
|
If you are only inheriting from one preset, the syntax ``preset: "parent_preset"`` is
|
|
valid YAML. Inheriting from multiple presets require use of a list.
|
|
|
|
.. _`mergedeep`:
|
|
https://mergedeep.readthedocs.io/en/latest/
|
|
.. _`a TYPESAFE_ADDITIVE merge`:
|
|
https://mergedeep.readthedocs.io/en/latest/index.html#merge-strategies
|