These are redirects and should be avoided to save http requests.

The script handles more than just directors now.

• flox build is not a thing
• populate only creates directors; need to run-all after it to populate films / offers / ...

This is not going to be just about movies or Letterboxd, probably. Perhaps better to do the rename earlier.

This media state can later be used to adjust recommendations according to what the user owns already.

Make sure all resources are updated once in a while.

Steps to implement

• activate flox environment.
• make install
• make init_db && populate
• make webapp
• run a CLI client against the webapp and confirm it returns something sane. (TODO: need to implement the client first)

Right now, updated_at is always bumped, which makes directors never actually update. updated_at should be only updated when the actual update happened; we may need a separate field to track check timestamps. (Alembic integration is needed for proper db migration.)

There's some common logic in different resource types (e.g. using multiplier = 1 as a base), that should be extracted into general machinery.

Postgres will do probably.

On director update, a movie may be detached from a director; or perhaps moved to a new text-slug. In this case, the old record is left in the database. This should be cleaned up.

sqlite is not very flexible, and it may be useful to keep htmls as files for further processing in this or other projects.

Since the cache is already in sqlite db, I'll need to migrate it from there.

Right now, the assumption is that I have the full list of directors; I may not (esp. as new directors are born). I should try to find new ones somehow, e.g. by following paths from other crew members (first just other directors, but paths through actors and other staff is probably more promising, since directors don't usually work together; but actors do.)

Preferences can be pulled from e.g. goodreads.

Note: the size of the database may be enormous because the high number of books, comparing to e.g. movies.

This is a meta ticket. I would have to resolve a number of issues before I can proceed. E.g. authN, security, scale etc. This is aspirational for now.

Preferences can be extracted from services like spotify or last.fm. Information about releases can be extracted from RYM.

Before touching the database, we should probably make a check that what external apis return returns expected format.

Right now these are

    "cli-color-py",
    "simple-justwatch-python-api",

The former is not needed except in recommend script that is obsolete; the latter is already kinda forked and we should probably just ditch it and have something in-house to talk graphql.

Can be useful to answer questions about new additions.

The page would consume a config (first global, then per-profile) and produce report page. The report generation should be independent of representation so that I can later generate e.g. emails of the same.

This would probably build on top of RAG extractor that would consume markdown knowledge base (tracked elsewhere).