Options for graby-site-config update outside of release schedule

[shtrom]

Issue details

When fixing issues with fetching, one often find themselves updating graby-site-config manually. I also suspect graby itself may need to be updated to more recent versions, as f43.me now seems to fare better on a number of links where Wallabag 2.3.2 fails, with or without site-config (I assume it's because there has been updates to graby since the las Wallabag release). This is all a bit dodgy because this means going into package-owned data, and swapping directories around like there's no tomorrow.

I wonder if we could set up some sort of mechanism so thos two repos can be updated out of the Wallabag release cycle. Various options:

• Onus on packagers: package those vendors as separate packages from the same source, and release them more often (say, after a composer update. Debian does this for some packages where the data moves must faster than the program (things like foomatic-db, usb-modeswitch-data or geoip-database)
• Support from Wallabag (not incompatible with the point above): support alternative, non-package-owned and configurable paths for those vendors, that would override the normal vendors if available. That would probably mess a bit with the autoload, but this would allow to point Wallabag to, say, a git checkout of graby-site-config's master
• Let Wallabag do the update: pretty self-explanatory, but I don't like this idea too much, as it would fiddle with package-installed data.

My favourite is the second one, but I'm not entirely sure how to do it.

[j0k3r]

Updating graby might be too complex because it involve PHP code. Updating graby-site-config is less complex because it's just plain file.

There is already an issue about that #1284
You can check the above issue and post your opinion. I'll close this one as duplicate.