Clarify remote_priority?

[Schweinepriester]

State of remote_priority unclear

Running my config, including

fetchart: 
    remote_priority: yes

leads to

fetchart: The `fetch_art.remote_priority` configuration option has been deprecated, see the documentation.

which doesn't seem to be explained in the documentation.

Searching the repo didnt really yield something.

Please clarify/update the docs? :)

As always: Thanks! :)

---

PS: 1.3.19 identifies itself as 1.3.18?

PS C:\Users\Kai> pip list
beets (1.3.19)
…
PS C:\Users\Kai> beet version
fetchart: The `fetch_art.remote_priority` configuration option has been deprecated, see the documentation.
beets version 1.3.18

kk, saw #2086!

[wisp3rwind]

Around March or April I did some refactoring of the source handling in the fetchart module to unify how remote art sources and pictures found on the filesystem are handled. In the process, the ability to specify filesystem in sources was added.

So instead of

remote_priority: true
sources: fanarttv google

you can now just say

sources: filesystem fanarttv google

which at least I liked better; also as it is right now there is code for reading both (redundant) configuration formats in order to be backwards compatible. I don't know whether it is really relevant to anyone, but the new format is actually more powerful since it allows for things such as

sources: fanarttv filesystem google

where you would want to refresh album art if it can be found on a higher-quality source, and prefer local pictures to lower-quality online sources. (Actually, the idea doesn't seem too bad, I'll have a look at my config 😆)

I'll look into hinting more directly at this in the docs.

On the other hand, keeping that message forever is not so nice either. What do others think; has a widely used config option ever been dropped in beets? Or should we just be silent about this? @sampsyo?

[sampsyo]

Good explanation! Yes, maybe a short section in the docs could explain that you can just place filesystem at the beginning of the list. The deprecation message could even hint at this (e.g., "Instead, place filesystem at the end of your sources list.")

As for a general policy, we don't have a concrete one—but the de facto policy has been to mostly leave this kind of message in place indefinitely unless it's causing a problem. For example, there's this color depreciation message that's been around for quite a while—it's not really hurting anyone to keep it there, so it doesn't seem urgent to remove it.