thp / urlwatch

Watch (parts of) webpages and get notified when something changes via e-mail, on your phone or via other means. Highly configurable.
https://thp.io/2008/urlwatch/
Other
2.79k stars 350 forks source link

FEATURE: Support multiple reporters with different options #790

Open Jamstah opened 5 months ago

Jamstah commented 5 months ago

Interested in thoughts of this style of config

report:
  text: # Still have these for inheritance
    details: true
    footer: true
    line_length: 75
    minimal: false
  html:
    diff: unified
  reporters:
  - type: email
    enabled: true
    from: your.username@gmail.com
    to: person1@domain.net
    method: sendmail
    tags: tag1
  - type: email
    enabled: true
    from: your.username@gmail.com
    to: person2@domain.net
    method: sendmail
    tags: tag2
    html: true
  - type: stdout
    color: true
    enabled: true
  telegram: # Still support dict format
    bot_token: ''
    chat_id: ''
    enabled: false
thp commented 5 months ago

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: your.username@gmail.com
      to: person1@domain.net
      method: sendmail
      tags: tag1
    - enabled: true
      from: your.username@gmail.com
      to: person2@domain.net
      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?

Jamstah commented 5 months ago

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.

thp commented 5 months ago

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?).

Jamstah commented 5 months ago

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

Jamstah commented 4 months ago

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

thp commented 2 months ago

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.