Are we interested in adding the --no-config-locations flag to yt-dlp

[HirschBerge]

I, and I'm sure others, have custom configs for yt-dlp for resolution, download location, etc.

These can interfere with ani-cli's download when it's through yt-dlp. Before I submit a PR to add the flag, is this something that we're interested in even having? I think this would give a guarantee to work as the most "intended" way. Instead of videos getting downloaded to ~/Videos/YouTube or some other magic location that isn't controlled by ani-cli

[port19x]

I wonder, does setting ANI_CLI_DOWNLOAD_DIR circumvent the issue?
This internally sets the output location via the -o flag for yt-dlp downloads.
If it does, I would prefer to keep things as is

[HirschBerge]

No, the actual flag for YTDlp overrides other methods.

I think a better solution to this would be to change the yt-dlp command to just have the following

yt-dlp ...  --paths "$download_dir" -o "$2.mp4"

This is more of the intended method from upstream anyways since it actually fits with using the rest of their automation tooling.

This could also be combined with --no-config-locations to provide the most vanilla experience without trampling on UX. To condense the code in the actual script it's possible to have a --config-locations flag (can be called multiple times) that can be used to load in an entire set of options specifically for ani-cli and allow users to troubleshoot with their own config file via an environment variable.

Personally, this would improve the flexibility of ani-cli immensely