Due to the failures related to symlinks in the repo directory that
happened when doing a full directory merge, the migration logic has been
simplified. It now only copies useful YAML files and cache data. The
repo directory is ignored and will need to be re-cloned when the user
runs `recyclarr` next time.
Symlinks are difficult to deal with. At this point, it was still failing
to migrate the `.config/recyclarr/repo` directory. Even though it still
doesn't work 100%, I'm going to leave it as it is and instead simplify
what gets migrated later.
Smarter migration logic that does a directory merge instead of a
straight move. This is designed to fail less in cases like the
`recyclarr` directory already existing.
Automatic migration no longer takes place. Instead, the user must run
`recyclarr migrate` to have those migration steps executed
automatically, or do it manually.
The logger, which also writes to a file in addition to console,
requires `IAppPaths` in order to find the directory to place the log
files. However, this cannot be obtained until the system calculates
the app data directory OR the user specifies it with the `--app-data`
option.
A custom sink has been added that will allow the logger to write to
console without file logs until that initialization is performed and
the log directory is available.
- Attempt to detect if `HOME` is defined and available. If not, error
out.
- Attempt to create `$HOME/.config` if `$HOME` is available.
- If logic in code attempts to grab the app data dir path before it's
set up, an exception is thrown.
Tests fail inconsistently between Linux & Windows if you hard-code paths
with forward or backward slashes. My hope was that `MockFileSystem`
converted the slashes for me, to assist in simpler unit testing.
The default is now located at `~/.config/recyclarr/recyclarr.yml`. The
previous location (next to the executable) is still supported, but
deprecated. A `recyclarr.yml` at the old/previous location will always
be loaded first.
There were some corner cases that were not handled (such as logging the
instance URL being processed). Additionally, code was simplified greatly
by centralizing the sanitization logic.
The goal is to separate initialization logic from command business
logic. Some initialization requires modifying the environment before we
instantiate many objects needed for implementing command behavior. If
those objects get instantiated, they will most likely already start
using files/directories/environment on the system and we can't modify
those while they're in use.
When using filters like `exclude`, it was possible for terms to not get
synced when they should have. This was due to a misunderstanding of how
`ExceptBy()` and `IntersectBy()` work. According to [an issue][1] on the
dotnet runtime repo, this is by design. The fix is to just avoid those
in favor of `Where()`.
Fixes#69.
[1]: https://github.com/dotnet/dotnet-api-docs/issues/7656
The removal of the markdown parsing logic in v2.0 accidentally also
deleted the logic responsible for handling this property. The code has
been refactored to introduce a "filter pipeline" system that handles
include/exclude filtering as well as strict negative score support.
Robert Dailey