In general, it's a good idea. And as long as the existing format is still supported, that shouldn't affect existing users.

Not too happy with "reporters" below "report".

We could do it without an additional key. By default, each immediate child (e.g. email) of "report" has as immediate child a dict (e.g. email has a dict with enabled, from, to, ...). If we add support for a list-of-dicts below each reporter, that could do the trick:

report:
  text: # Still have these for inheritance
    details: true
    footer: true
    line_length: 75
    minimal: false
  html:
    diff: unified
  email:
    - enabled: true
      from: [email protected]
      to: [email protected]
      method: sendmail
      tags: tag1
    - enabled: true
      from: [email protected]
      to: [email protected]
      method: sendmail
      tags: tag2
      html: true
  stdout:
    color: true
    enabled: true
  telegram: # Still support dict format
    bot_token: ''
    chat_id: ''
    enabled: false

This would probably be the least intrusive (no new keys), and should be super simple to check (if the immediate child is a dict, treat it as a single config, otherwise if it's a list, treat it as list of multiple configs).

Certain shared/superclass configs (e.g. text and html) obviously wouldn't have the possibility to be specified as list, as there can only be one. Then again, what if you want to have e.g. different text reporter configurations for each of the multiple e-mail reporters defined? This proposal doesn't support that, but maybe that's okay for a first version?

I think it's either make a compromise like either of our suggestions, or create a V2 config file format and redesign it with the new requirements in mind, supporting both formats for now.

I would probably go with a compromise and your option looks good. I'll propose an implementation based on the tagging at some point, when I next get a chance to look at it.

Great, I like the compromise (backwards compatible) variant better, because it means less disruption for existing users. And maybe you can split the possible PRs into two, once that adds multiple reporter configs, and then after that's been merged, a separate on that adds tagging on top (or I guess tagging could be done first, as these are mostly independent?).

I did tagging first because I already had that PR in flight :)

WIP on this, for after tags are merged in: https://github.com/thp/urlwatch/compare/master...Jamstah:multiple-reporters?expand=1

WIP on this, for after tags are merged in: https://github.com/thp/urlwatch/compare/master...Jamstah:multiple-reporters?expand=1

Tags is now merged if you want to tackle this, too.