this is necessary because otherwise artists with different string
representations but the same slug would overwrite one another
this outlines more clearly the code duplication between the rst code
and the slugify function, something which can be fixed later.
we write the artists files in a subdirectory, to avoid infinite
recursions or flooding the current directory needlessly.
this way, the user has a good base structure and can just chain the
command into sphinx to continue building the next format, after
possible tweaks.
skip was a misnomer: we actually skip "unfetched" lyrics. this means
it's somewhat of a double-negative and really confusing.
--local is clearer, although less in opposition with --force
this makes the ePUB easier to parse by e-readers, because they do not
need to load one giant HTML file, but one per author. it also makes
sphinx rendering more efficient and interactive
ReStructuredText has the advantage over HTML that it can be rendered
easily to multiple formats (HTML, ePUB, PDF) and it supports indexes.
the output needs to be fed into a file and integrated into an existing
Sphinx document, of course.
the idea here is to format the lyrics output a little better so that
it can (for example) be shown as a web page or an ebook.
the new skip option allows for faster generation of the output in the
(most common) case where not all lyrics are available.
We really want `Album.artpath` to be None sometimes, and this was relying on
some accidental dbcore behavior before. Now, we explicitly mark the field as
nullable: it may be a path, or it may be None to indicate that there is no
art.
This came out of an attempt to address the mysterious testing problems from
PR #2563 and turned into a big old debacle. As it turns out, the problem came
from calling Item.from_path and getting None for fields that weren't filled
out by the MediaFile data. Everywhere else, we fill out these fixed attributes
with the special null value for the field's type, so it's actually pretty
confusing that these could mysteriously become None. I think it will be saner
all around if we enforce this universally.
There were two possible fixes: one in __getitem__ to check for missing values
and one that set all the missing values in the constructor. I opted for the
former because it has a smaller footprint, but the latter might have slightly
better performance (depending on the ratio of constructions to lookups).
Changed the return in case of a relative date, by default precision is
to the second, aka 5
Removed old 'relative' precision that indeed isn't necessary anymore
Corrected doc according to current relative date format, no more @