Added some ADRs and libraries.

Signed-off-by: Cliff Hill <xlorep@darkhelm.org>

docs/adrs/000-template.md

@@ -0,0 +1,20 @@
+# ADR N: brief decision title
+
+Describe here the forces that influence the design decision, including technological, cost-related, and project local.
+
+## Decision
+
+Describe here our response to these forces, that is, the design decision that was made. State the decision in full sentences, with active voice ("We will...").
+
+## Rationale
+
+Describe here the rationale for the design decision. Also indicate the rationale for significant _rejected_ alternatives. This section may also indicate assumptions, constraints, requirements, and results of evaluations and experiments.
+
+## Status
+
+[Proposed | Accepted | Deprecated | Superseded]
+If deprecated, indicate why. If superseded, include a link to the new ADR.
+
+## Consequences
+
+Describe here the resulting context, after applying the decision. All consequences should be listed, not just the "positive" ones.

docs/adrs/001-async.md

@@ -0,0 +1,19 @@
+# ADR 001: Implement as asynchronous application
+
+Due to the multiple paths and processes that need to be run to gather and collect data over a network and the lack of need to synchronously process anything, it is found to be necessary to run the application in an asynchrounous manner,
+
+## Decision
+
+The application will be written using an asynchronous design. Selection of other libraries to use for the application will be focused on asynchronous libraries whenever possible. If no asynchronous library is possible/available, the use of threadpools and processpools will be determined on a case-by-case manner.
+
+## Rationale
+
+It makes more sense to build the application from the ground up as asynchronous rather than synchronous first and later asynchronous, as there will be less tech debt to make a decision like this up-front.
+
+## Status
+
+Accepted
+
+## Consequences
+
+There will likely be complications as expected from any concurrency operations which will need to be dealt with when they arise.

docs/adrs/002-toml.md

@@ -0,0 +1,23 @@
+# ADR 002: TOML
+
+A good configuration file format needs to be selected. There are three main choices that were considered:
+
+1. JSON - this is the primary data format used for the web and communications, but is not as readable as the other options.
+2. YAML - this is a much more readable format, and is a superset of JSON (able to load JSON as YAML), however there are weird nuances in this format that can cause problems.
+3. TOML - this is a format similar to the old Windows Config format, but with better structuring. It is readable, and clear like YAML, but without the weird corner cases that YAML has which could break things. However support is small as it is relatively new.
+
+## Decision
+
+TOML was decided to be used for the configuration file.
+
+## Rationale
+
+TOML is very readable, does not have the bizarre error problems that YAML does, and is an up-and-coming technology. While the support is relatively light right now, it already is showing up in the standard Python libraries, as well as a handful of other libraries.
+
+## Status
+
+Accepted
+
+## Consequences
+
+Using the `toml` library means accepting a relatively new library with a version 0.0, which could have issues until it matures to a full system. Might need to revisit and pick another library for the config files if the `toml` library doesn't work.

pyproject.toml

@@ -19,8 +19,10 @@ classifiers = [
 Changelog = "https://github.com/xlorepdarkhelm/plex-playlist/releases"
 
 [tool.poetry.dependencies]
-python = "^3.7"
+python = "^3.12"
 click = ">=8.0.1"
+toml = "^0.10.2"
+app-paths = "^0.0.7"
 
 [tool.poetry.dev-dependencies]
 Pygments = ">=2.10.0"